[BUG] intel_drv.so fails to load

[BUG] intel_drv.so fails to load

[Knut Petersen]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

Current Xorg tree builds without problems but fails to
load intel_drv.so. Xorg log and build script attached.

cu,
  Knut

[-- Attachment #2: Xorg.0.log --]
[-- Type: text/x-log, Size: 7981 bytes --]

[ 30172.250] 
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
[ 30172.255] 
X.Org X Server 1.12.99.901 (1.13.0 RC 1)
Release Date: 2012-07-10
[ 30172.267] X Protocol Version 11, Revision 0
[ 30172.271] Build Operating System: Linux 3.4.5-main i686 
[ 30172.275] Current Operating System: Linux golem 3.4.5-main #49 PREEMPT Tue Jul 17 08:18:29 CEST 2012 i686
[ 30172.275] Kernel command line: root=/dev/sdb2 acpi_enforce_resources=lax drm.debug=0 3
[ 30172.283] Build Date: 17 July 2012  08:28:13PM
[ 30172.287]  
[ 30172.290] Current version of pixman: 0.27.1
[ 30172.297] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[ 30172.297] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 30172.311] (==) Log file: "/home/knut/git/X11-t/var/log/Xorg.0.log", Time: Tue Jul 17 21:16:03 2012
[ 30172.336] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 30172.343] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 30172.347] (==) No Layout section.  Using the first Screen section.
[ 30172.347] (==) No screen section available. Using defaults.
[ 30172.347] (**) |-->Screen "Default Screen Section" (0)
[ 30172.347] (**) |   |-->Monitor "<default monitor>"
[ 30172.348] (==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
[ 30172.348] (**) |   |-->Device "Card0"
[ 30172.348] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[ 30172.349] (==) Automatically adding devices
[ 30172.349] (==) Automatically enabling devices
[ 30172.349] (==) Automatically adding GPU devices
[ 30172.349] (==) FontPath set to:
	/home/knut/git/X11-t/usr/share/fonts/X11/misc/,
	/home/knut/git/X11-t/usr/share/fonts/X11/TTF/,
	/home/knut/git/X11-t/usr/share/fonts/X11/OTF/,
	/home/knut/git/X11-t/usr/share/fonts/X11/Type1/,
	/home/knut/git/X11-t/usr/share/fonts/X11/100dpi/,
	/home/knut/git/X11-t/usr/share/fonts/X11/75dpi/
[ 30172.349] (==) ModulePath set to "/home/knut/git/X11-t/usr/lib/xorg/modules"
[ 30172.349] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 30172.349] (II) Loader magic: 0x82e8600
[ 30172.349] (II) Module ABI versions:
[ 30172.349] 	X.Org ANSI C Emulation: 0.4
[ 30172.349] 	X.Org Video Driver: 13.0
[ 30172.349] 	X.Org XInput driver : 18.0
[ 30172.349] 	X.Org Server Extension : 6.0
[ 30172.351] (II) config/udev: Adding drm device (/dev/dri/card0)
[ 30172.357] (--) PCI:*(0:0:2:0) 8086:2592:a0a0:0554 rev 4, Mem @ 0xd5280000/524288, 0xc0000000/268435456, 0xd5300000/262144, I/O @ 0x0000e000/8
[ 30172.358] (--) PCI: (0:0:2:1) 8086:2792:a0a0:0554 rev 4, Mem @ 0xd5200000/524288
[ 30172.358] (--) PCI: (0:5:5:0) 14f1:8800:0070:6906 rev 5, Mem @ 0xd1000000/16777216
[ 30172.358] (II) Open ACPI successful (/var/run/acpid.socket)
[ 30172.387] Initializing built-in extension Generic Event Extension
[ 30172.395] Initializing built-in extension SHAPE
[ 30172.401] Initializing built-in extension MIT-SHM
[ 30172.404] Initializing built-in extension XInputExtension
[ 30172.407] Initializing built-in extension XTEST
[ 30172.410] Initializing built-in extension BIG-REQUESTS
[ 30172.413] Initializing built-in extension SYNC
[ 30172.415] Initializing built-in extension XKEYBOARD
[ 30172.418] Initializing built-in extension XC-MISC
[ 30172.421] Initializing built-in extension XINERAMA
[ 30172.424] Initializing built-in extension XFIXES
[ 30172.426] Initializing built-in extension RENDER
[ 30172.429] Initializing built-in extension RANDR
[ 30172.431] Initializing built-in extension COMPOSITE
[ 30172.434] Initializing built-in extension DAMAGE
[ 30172.436] Initializing built-in extension MIT-SCREEN-SAVER
[ 30172.439] Initializing built-in extension DOUBLE-BUFFER
[ 30172.441] Initializing built-in extension RECORD
[ 30172.443] Initializing built-in extension DPMS
[ 30172.445] Initializing built-in extension X-Resource
[ 30172.447] Initializing built-in extension XVideo
[ 30172.450] Initializing built-in extension XVideo-MotionCompensation
[ 30172.452] Initializing built-in extension XFree86-VidModeExtension
[ 30172.454] Initializing built-in extension XFree86-DGA
[ 30172.456] Initializing built-in extension XFree86-DRI
[ 30172.458] Initializing built-in extension DRI2
[ 30172.458] (II) "glx" will be loaded by default.
[ 30172.458] (II) LoadModule: "dri"
[ 30172.458] (II) Module "dri" already built-in
[ 30172.458] (II) LoadModule: "dri2"
[ 30172.458] (II) Module "dri2" already built-in
[ 30172.458] (II) LoadModule: "vgahw"
[ 30172.459] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/libvgahw.so
[ 30172.460] (II) Module vgahw: vendor="X.Org Foundation"
[ 30172.460] 	compiled for 1.12.99.901, module version = 0.1.0
[ 30172.460] 	ABI class: X.Org Video Driver, version 13.0
[ 30172.460] (II) LoadModule: "fb"
[ 30172.461] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/libfb.so
[ 30172.479] (II) Module fb: vendor="X.Org Foundation"
[ 30172.479] 	compiled for 1.12.99.901, module version = 1.0.0
[ 30172.479] 	ABI class: X.Org ANSI C Emulation, version 0.4
[ 30172.479] (II) LoadModule: "xaa"
[ 30172.479] (WW) Warning, couldn't open module xaa
[ 30172.479] (II) UnloadModule: "xaa"
[ 30172.479] (II) Unloading xaa
[ 30172.479] (EE) Failed to load module "xaa" (module does not exist, 0)
[ 30172.479] (II) LoadModule: "int10"
[ 30172.480] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/libint10.so
[ 30172.493] (II) Module int10: vendor="X.Org Foundation"
[ 30172.493] 	compiled for 1.12.99.901, module version = 1.0.0
[ 30172.493] 	ABI class: X.Org Video Driver, version 13.0
[ 30172.493] (II) LoadModule: "vbe"
[ 30172.494] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/libvbe.so
[ 30172.500] (II) Module vbe: vendor="X.Org Foundation"
[ 30172.500] 	compiled for 1.12.99.901, module version = 1.1.0
[ 30172.500] 	ABI class: X.Org Video Driver, version 13.0
[ 30172.500] (II) LoadModule: "shadowfb"
[ 30172.501] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/libshadowfb.so
[ 30172.506] (II) Module shadowfb: vendor="X.Org Foundation"
[ 30172.506] 	compiled for 1.12.99.901, module version = 1.0.0
[ 30172.506] 	ABI class: X.Org ANSI C Emulation, version 0.4
[ 30172.506] (II) LoadModule: "glx"
[ 30172.507] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/extensions/libglx.so
[ 30172.567] (II) Module glx: vendor="X.Org Foundation"
[ 30172.567] 	compiled for 1.12.99.901, module version = 1.0.0
[ 30172.567] 	ABI class: X.Org Server Extension, version 6.0
[ 30172.567] (==) AIGLX enabled
[ 30172.571] Loading extension GLX
[ 30172.571] (II) LoadModule: "intel"
[ 30172.572] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so
[ 30172.594] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: I810RefreshRing
[ 30172.594] (II) UnloadModule: "intel"
[ 30172.594] (II) Unloading intel
[ 30172.594] (EE) Failed to load module "intel" (loader failed, 7)
[ 30172.594] (EE) No drivers available.
[ 30172.603] 
Fatal server error:
[ 30172.603] no screens found
[ 30172.606] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[ 30172.613] (EE) Please also check the log file at "/home/knut/git/X11-t/var/log/Xorg.0.log" for additional information.
[ 30172.616] (EE) 

[-- Attachment #3: compX-t --]
[-- Type: text/plain, Size: 1549 bytes --]

wol -h 192.168.22.255 00:01:80:62:cf:b1

export MYROOT=/home/knut/git/X11-t
export PREFIX=$MYROOT/usr
export EPREFIX=$PREFIX
export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig
export PATH=$PREFIX/bin:$PATH
export ACLOCAL="aclocal -I $PREFIX/share/aclocal"
export LD_LIBRARY_PATH=$PREFIX/lib
export PYTHONPATH=$PREFIX/lib/python2.7/site-packages


export MAKEFLAGS="-j 15"
export GMAKEFLAGS="-j 15"
export CC=/opt/icecream/bin/gcc
export CXX=/opt/icecream/bin/g++

export CFLAGS="-g2 -O3 --verbose -D MULTITOUCH"
export CXXFLAGS="-g2 -O3 "

export LD_PRELOAD=

cd /home/knut/git

util/modular/build.sh $PREFIX --modfile modules_to_build -a -n --cmd "git reset --hard"
util/modular/build.sh $PREFIX --modfile modules_to_build -a -n --cmd "git clean -dfx"
rm -rf $MYROOT
mkdir -p $PREFIX/usr
util/modular/build.sh $PREFIX --modfile modules_to_build -a -n --cmd "git log -n 1 --pretty=oneline" &> $PREFIX/../versions

cd mtdev-1.1.2
./configure --prefix=$PREFIX
make
make install
cd ..

export LD_PRELOAD=$PREFIX/lib/libmtdev.so

util/modular/build.sh  -g $PREFIX \
   --autoresume built-modules.txt \
   --modfile modules_to_build \
   --confflags " \
   --enable-kdrive \
   --with-dri-drivers=i915 \
   --with-gallium-drivers=i915 \
   --disable-xaa \
   --disable-gallium \
   --disable-radeon \
   --enable-gles1 \
   --enable-gles2 \
   --disable-docs \
   --disable-devel-docs \
   --disable-specs \
   --localstatedir=$MYROOT/var \
     --enable-config-dbus \
     --with-serverconfig-path=$PREFIX/share/X11/xorg.conf.d \
   "

[-- Attachment #4: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Chris Wilson]

On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> Current Xorg tree builds without problems but fails to
> load intel_drv.so. Xorg log and build script attached.

Ok, looks like the xaa removal from i810 was snafu. Let me split out the
common ring functions from the xaa acceleration routines...

In the meantime compile with --enable-kms-only.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG] intel_drv.so fails to load

[Chris Wilson]

On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> > Current Xorg tree builds without problems but fails to
> > load intel_drv.so. Xorg log and build script attached.
> 
> Ok, looks like the xaa removal from i810 was snafu. Let me split out the
> common ring functions from the xaa acceleration routines...

A second attempt is now online. If I got my grepping correct, only the
xaa specific routines are in i810_xaa.c and not built with
--disable-xaa.

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

> Ok, looks like the xaa removal from i810 was snafu. Let me split out the
> common ring functions from the xaa acceleration routines...
>
> In the meantime compile with --enable-kms-only.
> -Chris
>

Well, after compiling with --enable-kms-only the module is still broken.
But there are always some old xorg trees waiting on my disks ;-)

cu,
  Knut

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

Am 17.07.2012 22:41, schrieb Chris Wilson:
> On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
>>> Current Xorg tree builds without problems but fails to
>>> load intel_drv.so. Xorg log and build script attached.
>> Ok, looks like the xaa removal from i810 was snafu. Let me split out the
>> common ring functions from the xaa acceleration routines...
> A second attempt is now online. If I got my grepping correct, only the
> xaa specific routines are in i810_xaa.c and not built with
> --disable-xaa.

Some XAA code still waits for a sudden death:

[ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP

cu,
  Knut

Re: [BUG] intel_drv.so fails to load

[Adam Jackson]

On 7/17/12 4:54 PM, Knut Petersen wrote:
> Am 17.07.2012 22:41, schrieb Chris Wilson:
>> On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson
>> <chris@chris-wilson.co.uk> wrote:
>>> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen
>>> <Knut_Petersen@t-online.de> wrote:
>>>> Current Xorg tree builds without problems but fails to
>>>> load intel_drv.so. Xorg log and build script attached.
>>> Ok, looks like the xaa removal from i810 was snafu. Let me split out the
>>> common ring functions from the xaa acceleration routines...
>> A second attempt is now online. If I got my grepping correct, only the
>> xaa specific routines are in i810_xaa.c and not built with
>> --disable-xaa.
>
> Some XAA code still waits for a sudden death:
>
> [ 35756.654] (EE) Failed to load
> /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
> /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
> undefined symbol: XAAGetPatternROP

That's... surprising.  That should only be fatal if you have LD_BIND_NOW 
semantics turned on, which is not the default.  What OS are you running? 
  Any special security or compiler options?

- ajax

Re: [BUG] intel_drv.so fails to load

[Chris Wilson]

On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> Am 17.07.2012 22:41, schrieb Chris Wilson:
> > On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >> On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> >>> Current Xorg tree builds without problems but fails to
> >>> load intel_drv.so. Xorg log and build script attached.
> >> Ok, looks like the xaa removal from i810 was snafu. Let me split out the
> >> common ring functions from the xaa acceleration routines...
> > A second attempt is now online. If I got my grepping correct, only the
> > xaa specific routines are in i810_xaa.c and not built with
> > --disable-xaa.
> 
> Some XAA code still waits for a sudden death:
> 
> [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP

Ok, pushed yet another patch to reimplement those tables within i810. I
couldn't spot any more obvious XAA functions called from i810_accel, so
hopefully this will be the last iteration!

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

[-- Attachment #1.1: Type: text/plain, Size: 723 bytes --]


>> /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
>> undefined symbol: XAAGetPatternROP
>
> That's... surprising.  That should only be fatal if you have LD_BIND_NOW semantics turned on, which is not the default.  What OS are you running?  Any special security or compiler options?
>
> - ajax
>

openSuSE 12.1, 32 bit.

Hardware: Pentium M Dothan, AOpen i915GMm-HFS motherboard, 2GB RAM.

LD*: Nothing special in /etc/ld.so.conf or /etc/ld.so.conf.d/*, nothing special in environment.

Adam, we discussed LD problems in 2011. see Bug 41208 <https://bugs.freedesktop.org/show_bug.cgi?id=41208>. Xorg still does not start
here without a manually constructed modules section in the config file.

cu,
  Knut



[-- Attachment #1.2: Type: text/html, Size: 1297 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

>>> A second attempt is now online. If I got my grepping correct, only the
>>> xaa specific routines are in i810_xaa.c and not built with
>>> --disable-xaa.
>> Some XAA code still waits for a sudden death:
>>
>> [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP
> Ok, pushed yet another patch to reimplement those tables within i810. I
> couldn't spot any more obvious XAA functions called from i810_accel, so
> hopefully this will be the last iteration!

Yep, that´s it. 7752064 is running fine.

Thanks,
Knut
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 744 bytes --]

On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
> On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> > Some XAA code still waits for a sudden death:
> > 
> > [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP
> 
> Ok, pushed yet another patch to reimplement those tables within i810. I
> couldn't spot any more obvious XAA functions called from i810_accel, so
> hopefully this will be the last iteration!

Sigh.  Wish you hadn't, the linker behaviour he's seeing is _broken_.
Just because we don't know why doesn't make it not a bug.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Chris Wilson]

On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson <ajax@redhat.com> wrote:
> On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
> > On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> > > Some XAA code still waits for a sudden death:
> > > 
> > > [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP
> > 
> > Ok, pushed yet another patch to reimplement those tables within i810. I
> > couldn't spot any more obvious XAA functions called from i810_accel, so
> > hopefully this will be the last iteration!
> 
> Sigh.  Wish you hadn't, the linker behaviour he's seeing is _broken_.
> Just because we don't know why doesn't make it not a bug.

Except it also meant that i810 was indeed broken since it was unusing
undefined symbols.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG] intel_drv.so fails to load

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 2366 bytes --]

On Wed, 2012-07-18 at 15:07 +0100, Chris Wilson wrote:
> On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson <ajax@redhat.com> wrote:
> > On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
> > > On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> > > > Some XAA code still waits for a sudden death:
> > > > 
> > > > [ 35756.654] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP
> > > 
> > > Ok, pushed yet another patch to reimplement those tables within i810. I
> > > couldn't spot any more obvious XAA functions called from i810_accel, so
> > > hopefully this will be the last iteration!
> > 
> > Sigh.  Wish you hadn't, the linker behaviour he's seeing is _broken_.
> > Just because we don't know why doesn't make it not a bug.
> 
> Except it also meant that i810 was indeed broken since it was unusing
> undefined symbols.

No, not the case.

Normal ELF behaviour is that external data references are resolved at
object load time, but that function references are resolved when they
are first called; this is an optimization for app startup time.  The
former case is not what's going on here, because we're not taking the
address of XAAGetPatternROP (a data reference), we're calling it (a
function reference):

hate:~/driver/xf86-video-intel% git grep XAAGetPatternROP
src/legacy/i810/i810_accel.c:               (XAAGetPatternROP(rop) << 16) |
src/legacy/i810/i810_xaa.c:   pI810->BR[13] |= XAAGetPatternROP(rop) << 16;

So those should resolve lazily, which means if you never call them they
never _need_ to resolve.  And this is how X drivers normally work,
notice that libfb isn't loaded _before_ you load your driver but yet the
driver loads.

And we know the failure case here is not "failing to lazily resolve",
because if we were hitting _that_ we wouldn't see the error message he's
seeing, ld.so would just bitch on stderr and _exit().  The error message
he's seeing is dlopen() failing.

So this really honestly is a toolchain problem, not a driver problem.

Knut, can you send me a copy of your driver binary?  I'm really curious
to see where that data reference is coming from, assuming BIND_NOW is
not what we're seeing.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Chris Wilson]

On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson <ajax@redhat.com> wrote:
> So those should resolve lazily, which means if you never call them they
> never _need_ to resolve.  And this is how X drivers normally work,
> notice that libfb isn't loaded _before_ you load your driver but yet the
> driver loads.

They were being used by i810_dri.c, so i810 was busted. It just happened
to be that the first user to spot this was not using i810.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

>>>> Ok, pushed yet another patch to reimplement those tables within i810. I
>>>> couldn't spot any more obvious XAA functions called from i810_accel, so
>>>> hopefully this will be the last iteration!
>>> Sigh.  Wish you hadn't, the linker behaviour he's seeing is _broken_.
>>> Just because we don't know why doesn't make it not a bug.
>> Except it also meant that i810 was indeed broken since it was unusing
>> undefined symbols.
> No, not the case.
>
> Normal ELF behaviour is that external data references are resolved at
> object load time, but that function references are resolved when they
> are first called; this is an optimization for app startup time.  The
> former case is not what's going on here, because we're not taking the
> address of XAAGetPatternROP (a data reference), we're calling it (a
> function reference):
>
> hate:~/driver/xf86-video-intel% git grep XAAGetPatternROP
> src/legacy/i810/i810_accel.c:               (XAAGetPatternROP(rop) << 16) |
> src/legacy/i810/i810_xaa.c:   pI810->BR[13] |= XAAGetPatternROP(rop) << 16;
>
> So those should resolve lazily, which means if you never call them they
> never _need_ to resolve.  And this is how X drivers normally work,
> notice that libfb isn't loaded _before_ you load your driver but yet the
> driver loads.
>
> And we know the failure case here is not "failing to lazily resolve",
> because if we were hitting _that_ we wouldn't see the error message he's
> seeing, ld.so would just bitch on stderr and _exit().  The error message
> he's seeing is dlopen() failing.
>
> So this really honestly is a toolchain problem, not a driver problem.
>
> Knut, can you send me a copy of your driver binary?  I'm really curious
> to see where that data reference is coming from, assuming BIND_NOW is
> not what we're seeing.

Ok, I built caef63e0268e59e439b030a9a338e81d5cf8e311 using

export MYROOT=/home/knut/git/X11-t
export PREFIX=$MYROOT/usr
export EPREFIX=$PREFIX
export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig
export PATH=$PREFIX/bin:$PATH
export ACLOCAL="aclocal -I $PREFIX/share/aclocal"
export LD_LIBRARY_PATH=$PREFIX/lib
export PYTHONPATH=$PREFIX/lib/python2.7/site-packages
export MAKEFLAGS="-j 15"
export GMAKEFLAGS="-j 15"
export CC=/opt/icecream/bin/gcc
export CXX=/opt/icecream/bin/g++
export CFLAGS="-g2 -O3 --verbose -D MULTITOUCH"
export CXXFLAGS="-g2 -O3 "
export LD_PRELOAD=$PREFIX/lib/libmtdev.so
util/modular/build.sh -g $PREFIX -o driver/xf86-video-intel --confflags "--disable-xaa  --localstatedir=$MYROOT/var"

and got the following log entries:

[107706.682] (II) LoadModule: "intel"
[107706.682] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so
[107706.700] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP
[107706.700] (II) UnloadModule: "intel"
[107706.700] (II) Unloading intel
[107706.700] (EE) Failed to load module "intel" (loader failed, 7)
[107706.700] (EE) No drivers available.
[107706.709]
Fatal server error:
[107706.709] no screens found

Bad behaviour restored.

I modified my run script to contain LD_DEBUG*

    export PREFIX=/home/knut/git/X11-t/usr
    export PATH=$PREFIX/bin:$PATH
    export LD_LIBRARY_PATH=$PREFIX/lib
    export LD_PRELOAD=$PREFIX/lib/libmtdev.so
    export LD_DEBUG=all
    export LD_DEBUG_OUTPUT=/home/knut/git/X11-t/ld_debug_output
    /home/knut/startx -- $PREFIX/bin/Xorg

and executed it as root. Xorg still fails (nothing else had to be expected).
The log is too big for the mailing list, but:

knut@golem:~/git/X11-t> grep "relocation processing" ld_debug_output.28936
      28936:     relocation processing: /lib/libc.so.6
      28936:     relocation processing: /lib/libgpg-error.so.0 (lazy)
      28936:     relocation processing: /lib/libpthread.so.0 (lazy)
      28936:     relocation processing: /lib/librt.so.1 (lazy)
      28936:     relocation processing: /lib/libm.so.6 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libXdmcp.so.6 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libXau.so.6 (lazy)
      28936:     relocation processing: /lib/libz.so.1
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libfontenc.so.1 (lazy)
      28936:     relocation processing: /usr/lib/libfreetype.so.6 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libXfont.so.1 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libpixman-1.so.0 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libdrm.so.2 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libpciaccess.so.0 (lazy)
      28936:     relocation processing: /lib/libdl.so.2 (lazy)
      28936:     relocation processing: /lib/libgcrypt.so.11 (lazy)
      28936:     relocation processing: /lib/libudev.so.0 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libmtdev.so (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/bin/Xorg (lazy)
      28936:     relocation processing: /lib/ld-linux.so.2
      28936:     relocation processing: /lib/libgcc_s.so.1 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/xorg/modules/libvgahw.so (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/xorg/modules/libfb.so (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/xorg/modules/libint10.so (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/xorg/modules/libvbe.so (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/xorg/modules/libshadowfb.so (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/xorg/modules/extensions/libglx.so (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/libdrm_intel.so.1 (lazy)
      28936:     relocation processing: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so (lazy)

So relocation processing is done LAZY. At least that´s what the tool believes.

This is an opensuse system. All tools are those from the distro,
I´m not the only one using them. My system behaves this way in
version 12.1, and it behaved so in 11.4.

I have absolutely no idea why ld seems to fail in lazy relocation processing.

Adam, you´ll receive the binary and the full ld log as pm.

cu,
  Knut
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 2698 bytes --]

On Wed, 2012-07-18 at 20:04 +0200, Knut Petersen wrote:

> Ok, I built caef63e0268e59e439b030a9a338e81d5cf8e311 using
> 
> export MYROOT=/home/knut/git/X11-t
> export PREFIX=$MYROOT/usr
> export EPREFIX=$PREFIX
> export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig
> export PATH=$PREFIX/bin:$PATH
> export ACLOCAL="aclocal -I $PREFIX/share/aclocal"
> export LD_LIBRARY_PATH=$PREFIX/lib
> export PYTHONPATH=$PREFIX/lib/python2.7/site-packages
> export MAKEFLAGS="-j 15"
> export GMAKEFLAGS="-j 15"
> export CC=/opt/icecream/bin/gcc
> export CXX=/opt/icecream/bin/g++
> export CFLAGS="-g2 -O3 --verbose -D MULTITOUCH"
> export CXXFLAGS="-g2 -O3 "
> export LD_PRELOAD=$PREFIX/lib/libmtdev.so
> util/modular/build.sh -g $PREFIX -o driver/xf86-video-intel --confflags "--disable-xaa  --localstatedir=$MYROOT/var"
> 
> and got the following log entries:
> 
> [107706.682] (II) LoadModule: "intel"
> [107706.682] (II) Loading /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so
> [107706.700] (EE) Failed to load /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: XAAGetPatternROP
> [107706.700] (II) UnloadModule: "intel"
> [107706.700] (II) Unloading intel
> [107706.700] (EE) Failed to load module "intel" (loader failed, 7)
> [107706.700] (EE) No drivers available.
> [107706.709]
> Fatal server error:
> [107706.709] no screens found
> 
> Bad behaviour restored.

So, one difference between the driver you built and the driver in
factory:

http://download.opensuse.org/pub/opensuse/factory/repo/oss/suse/i586/xf86-video-intel-2.20.0-1.1.i586.rpm

Is that yours has this, and theirs doesn't:

hate:~% eu-readelf -a intel_drv.so | grep TEXTREL
  TEXTREL           
  FLAGS             TEXTREL

This suggests that you managed to build the X driver without -fPIC, and
eu-findtextrel(1) agrees.  This would cause the problem if text
relocations are also not lazy, and I believe that to be the case. [1]
To verify this assumption you could just jam -fPIC into CFLAGS and see
if the result works, but that's just papering over the bug, not
necessarily a fix.

I have no idea _how_ you managed to build it that way though.  I would
start by inspecting config.log and libtool from the build tree, or by
pointing $CC at real local gcc instead of icecream.

[1] - This, I think, is more artifact of implementation rather than
something done of necessity, but since textrels in DSOs are an i686ism
as far as Linux is concerned - and generally frowned upon even there -
it would be a lot of typing for little benefit.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1742 bytes --]

On Wed, 2012-07-18 at 15:36 +0100, Chris Wilson wrote:
> On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson <ajax@redhat.com> wrote:
> > So those should resolve lazily, which means if you never call them they
> > never _need_ to resolve.  And this is how X drivers normally work,
> > notice that libfb isn't loaded _before_ you load your driver but yet the
> > driver loads.
> 
> They were being used by i810_dri.c, so i810 was busted. It just happened
> to be that the first user to spot this was not using i810.

Ennh.  PreInit does:

---
   if (xf86ReturnOptValBool(pI810->Options, OPTION_NOACCEL, FALSE))
      pI810->noAccel = TRUE;

   if (!pI810->noAccel) {
      if (!xf86LoadSubModule(scrn, "xaa")) {
         I810FreeRec(scrn);
         return FALSE;
      }
   }

#ifdef HAVE_DRI1
   pI810->directRenderingDisabled =
     !xf86ReturnOptValBool(pI810->Options, OPTION_DRI, TRUE);

   if (!pI810->directRenderingDisabled) {
     if (pI810->noAccel) {
       xf86DrvMsg(scrn->scrnIndex, X_WARNING, "DRI is disabled because it "
                  "needs 2D acceleration.\n");
       pI810->directRenderingDisabled=TRUE;
     } else if (scrn->depth!=16) {
       xf86DrvMsg(scrn->scrnIndex, X_WARNING, "DRI is disabled because it "
                  "runs only at 16-bit depth.\n");
       pI810->directRenderingDisabled=TRUE;
     }
   }
#endif
---

So we default to asking for XAA, and if it doesn't load (because you
built without it) then neither will the driver; conversely, if XAA
loads, DRI's use of XAA symbols would be safe.  You'd have to have asked
for Option "NoAccel" to hit that bug.

It's not clear to me if, subsequent to your change, DRI would work with
NoAccel.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Chris Wilson]

On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson <ajax@redhat.com> wrote:
> So we default to asking for XAA, and if it doesn't load (because you
> built without it) then neither will the driver; conversely, if XAA
> loads, DRI's use of XAA symbols would be safe.  You'd have to have asked
> for Option "NoAccel" to hit that bug.

I had not noticed that the code still implied a dependence upon the XAA
module.
 
> It's not clear to me if, subsequent to your change, DRI would work with
> NoAccel.

It does. The mapping of the ring and control registers was already
managed outside of the XAA specific routines, so enabling the blit
function without the XAA infrastructure is fine.

Tested insofar as running glxgears on a remote i815 with XAA exorcised.
Not totally convinced I've verified all the necessary paths, but it
loads and seems to run.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

Am 18.07.2012 21:34, schrieb Adam Jackson:
> So, one difference between the driver you built and the driver in
> factory:
>
> http://download.opensuse.org/pub/opensuse/factory/repo/oss/suse/i586/xf86-video-intel-2.20.0-1.1.i586.rpm
>
> Is that yours has this, and theirs doesn't:
>
> hate:~% eu-readelf -a intel_drv.so | grep TEXTREL
>    TEXTREL
>    FLAGS             TEXTREL
>
> This suggests that you managed to build the X driver without -fPIC, and
> eu-findtextrel(1) agrees.  This would cause the problem if text
> relocations are also not lazy, and I believe that to be the case. [1]
> To verify this assumption you could just jam -fPIC into CFLAGS and see
> if the result works, but that's just papering over the bug, not
> necessarily a fix.

Argh. Adding -fPIC to the flags of an icecream compile run does help.
Somehow. dlopen no longer fails and the build succeeds. kde4init
hangs forever without any error message, but it is possible for programs
started at the framebuffer console to use the X server. I´ll have to investigate
this issue further.

cu,
  Knut
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [BUG] intel_drv.so fails to load

[Adam Jackson]

On 7/18/12 6:34 PM, Chris Wilson wrote:
> On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson <ajax@redhat.com> wrote:
>> It's not clear to me if, subsequent to your change, DRI would work with
>> NoAccel.
>
> It does. The mapping of the ring and control registers was already
> managed outside of the XAA specific routines, so enabling the blit
> function without the XAA infrastructure is fine.
>
> Tested insofar as running glxgears on a remote i815 with XAA exorcised.
> Not totally convinced I've verified all the necessary paths, but it
> loads and seems to run.

Hah, nice, sounds like all one could expect from an i815.

- ajax

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

Am 18.07.2012 16:29, schrieb Adam Jackson:
> So this really honestly is a toolchain problem, not a driver problem.

Neither icecream nor gcc are broken.

The solution is pretty simple:

====================================
Never ever include -v or --verbose in CFLAGS
====================================

Why?

Because otherwise there will be some output to
stdout during the -fPIC test compile executed from
configure, and that output causes the build system
to erroneously assume that -fPIC does not work.

Hence xorg parts that normally would be build with
-fPIC will be built without that flag.

The resulting Xorg server will fail to start with the
normal configuration setup as lazy resolution is
assumed but impossible. It will work perfectly if
you add  a suitable  Section "Module" that loads
all necessary modules in the right order.

I think the test for "-fPIC" support is fundamentally
broken and should be fixed. Or would it be better
to check for -v and --verbose in CFLAGS?

cu,
  Knut

Re: [BUG] intel_drv.so fails to load

[Adam Jackson]

On 7/20/12 8:03 AM, Knut Petersen wrote:
> Am 18.07.2012 16:29, schrieb Adam Jackson:
>> So this really honestly is a toolchain problem, not a driver problem.
>
> Neither icecream nor gcc are broken.
>
> The solution is pretty simple:
>
> ====================================
> Never ever include -v or --verbose in CFLAGS
> ====================================
>
> Why?
>
> Because otherwise there will be some output to
> stdout during the -fPIC test compile executed from
> configure, and that output causes the build system
> to erroneously assume that -fPIC does not work.
>
> Hence xorg parts that normally would be build with
> -fPIC will be built without that flag.

autoconf bug!  Nice find.

> I think the test for "-fPIC" support is fundamentally
> broken and should be fixed. Or would it be better
> to check for -v and --verbose in CFLAGS?

It sounds like the test is broken, yeah.  Although I wonder how many 
other standard autoconf tests have this property.

- ajax

Re: [BUG] intel_drv.so fails to load

[Knut Petersen]

Am 20.07.2012 17:10, schrieb Adam Jackson:
>
> autoconf bug!  Nice find.
>
>> I think the test for "-fPIC" support is fundamentally
>> broken and should be fixed. Or would it be better
>> to check for -v and --verbose in CFLAGS?
>
> It sounds like the test is broken, yeah.  Although I wonder how many other standard autoconf tests have this property.
>

A quick inspection shows that at least three tests share the same mechanism/problem.

cu,
  Knut