Bug 30451

Summary: error: ‘struct _ScrnInfoRec’ has no member named ‘pixmapPrivate’
Product: xorg Reporter: Jos van Wolput <wolput>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: David.Ronis, mgorny, SpOeK, Tomas.Klimek
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xorg.log
none
Combined pixmapPrivate and udev patch for src/drmmode_display.c none

Description Jos van Wolput 2010-09-29 02:31:13 UTC
After upgrading the video-ati driver and xserver to the latest git master version (xserver: Bump video driver ABI version to 9.0, Aaron Plattner), Xorg.0.log shows the following error:
---
[ 20895.992] (II) Module ati: vendor="X.Org Foundation"
[ 20895.992] 	compiled for 1.9.0, module version = 6.13.99
[ 20895.992] 	Module class: X.Org Video Driver
[ 20895.992] 	ABI class: X.Org Video Driver, version 8.0
[ 20895.992] (EE) module ABI major version (8) doesn't match the server's version (9)
[ 20895.992] (II) UnloadModule: "ati"
[ 20895.992] (II) Unloading ati
[ 20895.992] (EE) Failed to load module "ati" (module requirement mismatch, 0)
---
Comment 1 Michel Dänzer 2010-09-29 02:33:51 UTC
You need to rebuild the driver against the server.
Comment 2 Jos van Wolput 2010-09-29 03:15:26 UTC
(In reply to comment #1)
> You need to rebuild the driver against the server.

I did, but it doesn't compile:
---
drmmode_display.c: In function ‘drmmode_xf86crtc_resize’:
drmmode_display.c:1148:6: error: ‘struct _ScrnInfoRec’ has no member named ‘pixmapPrivate’
make[2]: *** [drmmode_display.lo] Error 1
make[2]: Leaving directory `/home/jos/src/xorg/git-master/xf86-video-ati/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jos/src/xorg/git-master/xf86-video-ati'
make: *** [all] Error 2
---
Comment 3 Jos van Wolput 2010-09-29 04:45:13 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > You need to rebuild the driver against the server.
> 
> I did, but it doesn't compile:
> ---
> drmmode_display.c: In function ‘drmmode_xf86crtc_resize’:
> drmmode_display.c:1148:6: error: ‘struct _ScrnInfoRec’ has no member named
> ‘pixmapPrivate’
> make[2]: *** [drmmode_display.lo] Error 1
> make[2]: Leaving directory `/home/jos/src/xorg/git-master/xf86-video-ati/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/jos/src/xorg/git-master/xf86-video-ati'
> make: *** [all] Error 2
> ---

No compilation error compiling against 58bd317e29f4abf7f950891339d2a6a78ddf7903
(Macpaul Lin, 6 days ago)
Comment 4 Jos van Wolput 2010-09-29 05:29:48 UTC
(In reply to comment #3)

THe first version of xserver against which the video-ati driver fails to compile is 5c6a2f93ebc16a78093782b442306de23ae94e78 (Chris Wilson)
Comment 5 Alex Deucher 2010-09-29 06:46:12 UTC
something like this should fix it:

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index a6038b2..7f54642 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1145,10 +1145,6 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, int height)
                                           width, height, -1, -1, pitch * cpp,
                                           info->fb_shadow);
        }
-       scrn->pixmapPrivate.ptr = ppix->devPrivate.ptr;
-
-       //      xf86DrvMsg(scrn->scrnIndex, X_INFO, "New front buffer at 0x%lx\n",
-       //                 info->front_bo-);
 
        for (i = 0; i < xf86_config->num_crtc; i++) {
                xf86CrtcPtr crtc = xf86_config->crtc[i];
Comment 6 Jos van Wolput 2010-09-29 07:25:37 UTC
(In reply to comment #5)

I tried your patch but get error:
~/src/xorg/git-master/xf86-video-ati$ git apply --check patch.txt
error: patch failed: src/drmmode_display.c:1145
error: src/drmmode_display.c: patch does not apply
Comment 7 Alex Deucher 2010-09-29 07:28:30 UTC
bugzilla mangled the patch since I just pasted it into the comments.  try applying it manually.
Comment 8 Jos van Wolput 2010-09-29 08:35:03 UTC
(In reply to comment #7)
> bugzilla mangled the patch since I just pasted it into the comments.  try
> applying it manually.

I applied your patch manually. No more compilation error but
xserver didn't work:
Fatal server error:
[ 48081.592] Caught signal 11 (Segmentation fault). Server aborting

I attach xorg.log
Comment 9 Jos van Wolput 2010-09-29 08:36:38 UTC
Created attachment 39048 [details]
xorg.log

Fatal server error:
[ 48081.592] Caught signal 11 (Segmentation fault). Server aborting
Comment 10 Andy Furniss 2010-09-29 09:31:58 UTC
(In reply to comment #9)
> Created an attachment (id=39048) [details]
> xorg.log
> 
> Fatal server error:
> [ 48081.592] Caught signal 11 (Segmentation fault). Server aborting

Strange it tries to load vesa.

I've just applied the patch and on my 32 bit setup xserver starts OK.

I always make distclean everything and also update/rebuild xf86-input-keyboard and xf86-input-mouse in addition to ati.
Comment 11 Jos van Wolput 2010-09-29 20:07:22 UTC
(In reply to comment #10)

The segfault shows up when using
xserver-5532687a929426c4b1c4667f4591ed362f097c9b.tar.bz2 (Keith Packard)
and following versions of xserver. (I first made distclean!)
The patch works well when using the previous versions of xserver.
Comment 12 Alex Deucher 2010-10-03 10:12:30 UTC
*** Bug 30578 has been marked as a duplicate of this bug. ***
Comment 13 David Ronis 2010-10-03 11:11:27 UTC
I too applied the patch.  startx gets further, but in the logs I see

/usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: udev_monitor_filter_add_match_subsystem_devtype
giving up.
xinit:  Connection refused (errno 111):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.
Comment 14 David Ronis 2010-10-03 11:34:36 UTC
This problem also arises in mesa:

In file included from xorg_driver.c:42:0:
/usr/include/xorg/edid.h:623:4: warning: declaration does not declare anything
xorg_driver.c: In function 'xorg_tracker_have_modesetting':
xorg_driver.c:125:5: warning: 'Xalloc' is deprecated (declared at /usr/include/xorg/os.h:221)
xorg_driver.c:133:2: warning: 'Xfree' is deprecated (declared at /usr/include/xorg/os.h:234)
xorg_driver.c:140:5: warning: 'Xfree' is deprecated (declared at /usr/include/xorg/os.h:234)
xorg_driver.c: In function 'drv_free_rec':
xorg_driver.c:177:5: warning: 'Xfree' is deprecated (declared at /usr/include/xorg/os.h:234)
xorg_driver.c: In function 'drv_init_drm':
xorg_driver.c:277:2: warning: 'Xalloc' is deprecated (declared at /usr/include/xorg/os.h:221)
xorg_driver.c:286:2: warning: 'Xfree' is deprecated (declared at /usr/include/xorg/os.h:234)
xorg_driver.c: In function 'drv_pre_init':
xorg_driver.c:447:5: warning: 'Xalloc' is deprecated (declared at /usr/include/xorg/os.h:221)
xorg_driver.c: In function 'drv_bind_front_buffer_kms':
xorg_driver.c:1188:10: error: 'struct _ScrnInfoRec' has no member named 'pixmapPrivate'
gmake[4]: *** [xorg_driver.o] Error 1
gmake[4]: Leaving directory `/home/ronis/Project/notar/X/mesa/src/gallium/state_trackers/xorg'
g
Comment 15 Andy Furniss 2010-10-03 12:16:38 UTC
(In reply to comment #13)
> I too applied the patch.  startx gets further, but in the logs I see
> 
> /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so:
> undefined symbol: udev_monitor_filter_add_match_subsystem_devtype
> giving up.
> xinit:  Connection refused (errno 111):  unable to connect to X server
> xinit:  No such process (errno 3):  Server error.

Hmm, maybe I lucked into a working setup because I don't use evdev on this old LFS setup, so have an xorg.conf with -

Section "ServerFlags"
 Option "AutoAddDevices" "off"
EndSection

As for mesa (maybe you know this anyway) you can workaround by adding to autogen options

--with-state-trackers=dri
Comment 16 David Ronis 2010-10-03 16:14:38 UTC
I added the autoadddevice option as suggested.  There is no change (no surprise really, since the load of the radeon driver is what's probably failing).

I was able to rebuild mesa with the --with-state-trackers=dri flag.  Can't test it though.
Comment 17 Jos van Wolput 2010-10-04 20:44:40 UTC
(In reply to comment #13)

After upgrading to the latest git versions (git pull, 2010-10-5) of xserver and video-ati and applying the patch, no more xserver errors, no more segmentation fault! 

Xorg.0.log:
X.Org X Server 1.9.99.1
[  7873.547] (II) LoadModule: "ati"
[  7873.548] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[  7873.548] (II) Module ati: vendor="X.Org Foundation"
[  7873.548] 	compiled for 1.9.99.1, module version = 6.13.99
[  7873.548] 	Module class: X.Org Video Driver
[  7873.548] 	ABI class: X.Org Video Driver, version 9.0
Comment 18 Jos van Wolput 2010-10-04 20:51:26 UTC
(In reply to comment #14)
> This problem also arises in mesa:
> 

I can confirm! I get the same error when compiling mesa with --enable-gallium.
Comment 19 David Ronis 2010-10-05 09:51:26 UTC
OK, I've just rebuilt/reinstalled xserver and xf86-video-ati.   Things now work provided:

1.  I turn off KMS in the kernel.

2.  I apply the patch to deal with pixmapPrivate

3.  Apply the patch (attached below) to deal with udev_monitor_filter_add_match_subsystem_devtype
 I'm on a slackware box, and I suspect that udev is too old.  Unfortunately so is libc and hence I've been unable to build my own udev.  I'd appreciate someone checking if I've broken something by simply dropping the call.
Comment 20 David Ronis 2010-10-05 09:53:18 UTC
Created attachment 39181 [details]
Combined pixmapPrivate and udev patch for src/drmmode_display.c
Comment 21 Jos van Wolput 2010-10-05 21:26:51 UTC
(In reply to comment #16)
> I was able to rebuild mesa with the --with-state-trackers=dri flag.  Can't test
> it though.

I tested a mesa rebuilt with the --with-state-trackers=dri flag, it works!
Comment 22 Witold Baryluk 2010-10-12 15:45:24 UTC
It looks that commit
commit 5c6a2f93ebc16a78093782b442306de23ae94e78
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Sep 27 19:39:23 2010 +0100

    xfree86: Kill pixmapPrivate with a vengeance (v2)

    ScrnInfo->pixmapPrivate only existed in order to catch invalid access to
    the framebuffer by making the backing data NULL across the VT switch.
    This was causing more confusion in the higher layers during mode setting
    without any real benefit, so remove it.
    
    v2: Kill ShadowModifyPixmapHeader() as well.

...

removed pixmapPrivate from  struct _ScrnInfoRec in xserver/hw/xfree86/common/xf86str.h

Author of the line in mesa which references (indicatted by git blame mesa/src/gallium/state_trackers/xorg/xorg_driver.c ) is

commit 6749310d...
Jakob Bornecrantz 2010-01-25 20:07:43 +0100

There is also a comment, which reads

    /* This a hack to work around EnableDisableFBAccess setting the pointer
     * the real fix would be to replace pScrn->EnableDisableFBAccess hook
     * and set the rootPixmap->devPrivate.ptr to something valid before that.
     *
     * But in its infinit visdome something uses either this some times before
     * that, so our hook doesn't get called before the crash happens.
     */
    pScrn->pixmapPrivate.ptr = ptr;



Apperently removing pScrn->pixmapPrivate.ptr = ptr, do not hurt...
Comment 23 Thomas Hellström 2010-10-14 11:52:44 UTC
There is a bit more to it.

The commit is a major ABI breakage, which means drivers compiled against previous X servers won't work anymore. Hence the major ABI number should have been updated. Likewise, any new driver releases simply removing this reference won't work against older X servers without compatibility code.
Comment 24 Alex Deucher 2010-10-19 14:15:43 UTC
fixed in 0f184630cd4760199430320215e4280438fc4ce5

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.