[SOLVED] Intel 82865g 2.6.33-smp kernel xorgserver 1.8, 2.11 driver version problem

matters · 05-16-2010, 02:23 AM

Hi all! Im having a battle for quite some time now with lastest intel driver now and wondering if someone has solution.

Ive checked : http://intellinuxgraphics.org/2010Q1.html and i decided to have exact same version of everything listed in there installed on the system.

I have few questions since i manually builded xorg-server 1.8 im wondering what packages are dependent for x11 to be upgraded so everything run smoothly for xserver 1.8. are those xf86-input* and xf86-video* the only one or there are other packages that i have to get rebuilded?

the second question: im wondering if im the only one for that having a problem of that lastest driver dosent work for me,

for the purpose i rebuilded the driver and libdrm 2.4.20 with kms enabled once i installed xorg-xserver 1.8.0

heres log problem:

Code:

214.704] (II) LoadModule: "intel"
[   214.704] (II) Loading /usr/lib/xorg/modules/intel_drv.so
[   214.704] dlopen: /usr/lib/xorg/modules/intel_drv.so: undefined symbol: resVgaShared
[   214.706] (EE) Failed to load /usr/lib/xorg/modules/intel_drv.so
[   214.707] (II) UnloadModule: "intel"
[   214.707] (EE) Failed to load module "intel" (loader failed, 7)
[   214.708] (II) LoadModule: "vesa"
[   214.709] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[   214.709] (II) Module vesa: vendor="X.Org Foundation"
[   214.709]    compiled for 1.8.0, module version = 2.3.0
[   214.709]    Module class: X.Org Video Driver
[   214.709]    ABI class: X.Org Video Driver, version 7.0

how can i fix the problem? is there a solution yet?
thanks

rworkman · 05-18-2010, 01:26 AM

That chipset works fine with the x11 packages in the stock -current tree.

matters · 05-19-2010, 05:10 AM

ive removed xorg-server 1.8, and then ive tried, again slackware current: executing commands in this order :

Code:

slackpkg update
slackpkg install-new
slackpkg upgrade-all
slackpkg install xorg-server
slackpkg reinstall x  ## i thouht it would reinstall all x11 packages,

and rebooted tried to remove vesa xorg.conf to see if it would work but no joy, same problem , cant load intel module properly.

heres log:

Code:

(II) Module dri2: vendor="X.Org Foundation"
        compiled for 1.7.7, module version = 1.1.0
        ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DRI2
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/intel_drv.so
dlopen: /usr/lib/xorg/modules/intel_drv.so: undefined symbol: resVgaShared
(EE) Failed to load /usr/lib/xorg/modules/intel_drv.so
(II) UnloadModule: "intel"
(EE) Failed to load module "intel" (loader failed, 7)
(II) LoadModule: "vesa"
(II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
(II) Module vesa: vendor="X.Org Foundation"
        compiled for 1.7.5, module version = 2.3.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 6.0

for me everything worked smoothly when in current stock was xorg-server 1.7.3 and ive builded from source libdrm and xf86-video-intel 2.10 kms enabled, after that i have this problem,

im wondering what this error cause:

Code:

/usr/lib/xorg/modules/intel_drv.so: undefined symbol: resVgaShared

what else can i try to fix the problem?

also what packages depends on xorg-server behaviour?

rworkman · 05-19-2010, 04:22 PM

I'm not sure where that symbol is coming from, but it means that some of your packages are not in sync with what's in our tree (or perhaps you have other stuff in /usr/local that's being seen).

matters · 05-20-2010, 09:33 AM

how can i locate where the symbol is coming from ?

ive done also

Code:

slackpkg clean-system

but the same thing no joy, what do you suggest i can try to make sure everything is in sync with stock current tree

its really interesting.

ive also downloaded stock current tree and done

Code:

 upgradepkg --reinstall */*.txz

but after reinstall no joy

ponce · 05-21-2010, 12:54 AM

if you don't have anything you need in /usr/local, you can try "resetting" it: maybe, as robby hinted above, something you build yourself has ended up installing there and it's loaded instead of the stuff in /usr.
so you can temporary move away the folders, create some pristine ones and see if it helps

Code:

cd /usr/local
mkdir old
mv bin old/
mv include old/
mv lib old/
mv man old/
mv sbin old/
mv share old/
mkdir bin
mkdir include
mkdir lib
mkdir man
mkdir sbin
mkdir share

if something breaks instead of fixing, you can put them back

but, in general and in particular with a complex package like X, it's very difficult to repair a situation where you don't know where your "make install"s have copied stuff...

matters · 05-21-2010, 02:33 AM

Quote:

Originally Posted by ponce

if you don't have anything you need in /usr/local, you can try "resetting" it: maybe, as robby hinted above, something you build yourself has ended up installing there and it's loaded instead of the stuff in /usr.
so you can temporary move away the folders, create some pristine ones and see if it helps

Code:

cd /usr/local
mkdir old
mv bin old/
mv include old/
mv lib old/
mv man old/
mv sbin old/
mv share old/
mkdir bin
mkdir include
mkdir lib
mkdir man
mkdir sbin
mkdir share

if something breaks instead of fixing, you can put them back

but, in general and in particular with a complex package like X, it's very difficult to repair a situation where you don't know where your "make install"s have copied stuff...

although all directories in /usr/local were empty except bin wich had bchunk file i followed your advice and no joy, same problem occurs.

we will see what kind of idea rworkman has

im wondering how i can trace from where undefined symbol is coming from?

thanks guys for helping me out

ponce · 05-21-2010, 03:59 AM

i don't know robby's idea, but if I were you I would do this (it's not a rude answer, just what I would do):
- backup personal data
- reinstall pristine -current from iso
- use packages/slackbuilds only

that will fix your problem faster than losing time trying to fix the symbol thing

matters · 05-21-2010, 08:10 AM

Quote:

Originally Posted by ponce

i don't know robby's idea, but if I were you I would do this (it's not a rude answer, just what I would do):
- backup personal data
- reinstall pristine -current from iso
- use packages/slackbuilds only

that will fix your problem faster than losing time trying to fix the symbol thing

the thing was old module from previous version of intel 2.10 was in /usr/lib/xorg/modules/intel_drv.so that i copied to by accident

and 2.11 was in /usr/lib/xorg/modules/drivers/intel_drv.so

so i had just to remove intel_drv.so from /usr/lib/xorg/modules and problem solved

im just wondering when you guys incorporate new xserver 1.8.0 version into stock-current tree is it really necessary to rebuild from scratch all x11 packages aswell?

ponce · 05-21-2010, 12:03 PM

I think yes, but someone more into building X than me (and maybe involved in the slackware team, but maybe you are referring to robby) can answer surely better.

also, if you search in the forum, there are some old threads about X building.

matters · 05-21-2010, 03:42 PM

its pointed to everyone, surely would like to know rworkman and other opinion about it,(although my opinion is just like yours, but want to check to make sure

) but im very glad that i got the solution to the problem

rworkman · 05-24-2010, 10:45 PM

Possibly you could be having issues with something that will be fixed in 2.6.33.5:

Code:

------------------
From: Jesse Barnes <jbarnes@virtuousgeek.org>

commit 1918ad77f7f908ed67cf37c505c6ad4ac52f1ecf upstream.

My PIPE_CONTROL fix (just sent via Eric's tree) was buggy; I was
testing a whole set of patches together and missed a conversion to the
new HAS_PIPE_CONTROL macro, which will cause breakage on non-Ironlake
965 class chips.  Fortunately, the fix is trivial and has been tested.

Be sure to use the HAS_PIPE_CONTROL macro in i915_get_gem_seqno, or
we'll end up reading the wrong graphics memory, likely causing hangs,
crashes, or worse.

Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Tested-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/gpu/drm/i915/i915_gem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1785,7 +1785,7 @@ i915_get_gem_seqno(struct drm_device *de
 {
        drm_i915_private_t *dev_priv = dev->dev_private;

-       if (IS_I965G(dev))
+       if (HAS_PIPE_CONTROL(dev))
                return ((volatile u32 *)(dev_priv->seqno_page))[0];
        else
                return READ_HWSP(dev_priv, I915_GEM_HWS_INDEX);

rworkman · 05-24-2010, 10:49 PM

Oh, I see that it's solved now :/

Re xorg-server-1.8.x, at least some of the video drivers will need a rebuild, and probably some of them won't build against it, and we'll have to work out the documentation side of "how do I do $x" with regards to setting keymaps using udev instead of hal, and while we're at it, we'll look into using udisks and upower for removable devices and power management, and then nothing will be left using hal, I don't think, but that will require testing, and if I'm right, we can remove hal, but then that will require lots of testing to make sure, so that's why we didn't shoot for the newer 1.8.x branch for 13.1. Long sentence, anyone? ;-)

matters · 05-25-2010, 12:56 AM

Quote:

Originally Posted by rworkman

Oh, I see that it's solved now :/

Re xorg-server-1.8.x, at least some of the video drivers will need a rebuild, and probably some of them won't build against it, and we'll have to work out the documentation side of "how do I do $x" with regards to setting keymaps using udev instead of hal, and while we're at it, we'll look into using udisks and upower for removable devices and power management, and then nothing will be left using hal, I don't think, but that will require testing, and if I'm right, we can remove hal, but then that will require lots of testing to make sure, so that's why we didn't shoot for the newer 1.8.x branch for 13.1. Long sentence, anyone? ;-)

Yes thats why i was thinking if everything has to be rebuilded.

Everything else clear, although its a bit long sentence.