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

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Intel 82865g 2.6.33-smp kernel xorgserver 1.8, 2.11 driver version problem (https://www.linuxquestions.org/questions/slackware-14/intel-82865g-2-6-33-smp-kernel-xorgserver-1-8-2-11-driver-version-problem-808105/)

matters

05-16-2010 02:23 AM

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

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 (Post 3976219)

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

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 (Post 3976359)

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 (Post 3980137)

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

Everything else clear, although its a bit long sentence.

All times are GMT -5. The time now is 11:02 PM.