Re: ioctl32 support
Donnie Berkholz wrote:
You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943.
I'm now stuck again with a strange crash. DRI clients
such as glxgears and glxinfo crash inside malloc(),
probably due to memory corruption:
---cut---
#0 0x006dec48 in _int_malloc () from /lib/libc.so.6
#1 0x006e06f2 in malloc () from /lib/libc.so.6
#2 0xf7f8165c in drmMalloc (size=512) at
../../../../r300_driver/drm.newioctl32/libdrm32/xf86drm.c:158
#3 0xf7f82d60 in drmMapBufs (fd=7) at
../../../../r300_driver/drm.newioctl32/libdrm32/xf86drm.c:1150
#4 0xf7d203e1 in radeonCreateScreen (sPriv=0x8056168) at radeon_screen.c:502
#5 0xf7d208b0 in radeonInitDriver (sPriv=0x8056168) at radeon_screen.c:653
#6 0xf7d1c497 in __driUtilCreateNewScreen (dpy=0x804c008, scrn=0,
psc=0x8054ed8, modes=0x0, ddx_version=0xb500,
---cut---
My feeling is this corruption might be caused by the kernel
stomping over user memory somewhere within ioctl32():
---cut---
ioctl(4, 0xc0086451, 0xcf44)= 0
ioctl(4, 0xc0086451, 0xcf44)= 0
ioctl(4, 0xc0086451, 0xcf44)= 0
mmap2(NULL, 524288, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0x8) =
0xefc49000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0x1000) =
0xefc48000
ioctl(4, 0xc00c6419, 0xcef4)= 0
ioctl(4, 0xc00c6419, 0xcef4)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
---cut---
(fd 4 is the card device)
I've tracked the last to ioctl() calls to drm_ioctl32.c:drm_buf_map_32_64(),
which I've instrumented with a few printk's, like so:
---cut---
static int
drm_buf_map_32_64(unsigned int fd, unsigned cmd,
unsigned long arg, struct file *file)
{
DECLARE_ARG32(drm32_buf_map_t);
DECLARE_ARG64_NOALLOC(drm_buf_map_t);
int err = 0;
drm32_buf_pub_t __user *list32;
drm_buf_pub_t __IOCTL32_USER *list64;
int i, count, tmp_count;
u64 tmp;
DUMMY_ARG;
DUMMY_ARG_P;
OLD_FS;
printk(KERN_DEBUG bernie: drm_buf_map_32_64: %d, %x, %lx, %p\n, fd, cmd,
arg, file);
if (get_user(count, ARG32(count)) || count 0) return -EFAULT;
if (get_user(tmp,ARG32(list))) return -EFAULT;
list32 = (drm32_buf_pub_t __user *) tmp;
printk(KERN_DEBUG bernie: count=%d\n, count);
K_ALLOC(list64, count * sizeof (drm_buf_pub_t));
if (!list64) return -EFAULT;
PUT_ARG64(list,list64);
GET_USER(count);
if (err) {
K_FREE(list64);
return -EFAULT;
}
SYS_IOCTL;
if (err) {
K_FREE(list64);
return err;
}
PUT_USER(count);
PUT_USER_P(virtual);
GET_ARG64(tmp_count,count);
if (count tmp_count) count = tmp_count;
for (i = 0 ; i count; i ++) {
printk(KERN_DEBUG bernie: i=%d, idx64=%d, total64=%d,
used64=%d,addr64=%d\n,
i, list64[i].idx, list64[i].total, list64[i].used,
list64[i].address);
PUT_USER_ARG(list64[i].idx,list32[i].idx);
PUT_USER_ARG(list64[i].total,list32[i].total);
PUT_USER_ARG(list64[i].used,list32[i].used);
PUT_USER_ARG_P(list64[i].address,list32[i].address);
}
K_FREE(list64);
return err ? -EFAULT : 0;
}
---cut---
And this is the dmesg output I get:
---cut---
bernie: drm_buf_map_32_64: 4, c00c6419, cef4, 81006f76f080
bernie: count=0
SYS_IOCTL_FUNC called
bernie: drm_buf_map_32_64: 4, c00c6419, cef4, 81006f76f080
bernie: count=32
SYS_IOCTL_FUNC called
bernie: i=0, idx64=134576296, total64=134573700, used64=-13364,addr64=134573688
bernie: i=1, idx64=-13336, total64=10282607, used64=134590276,addr64=-13160
bernie: i=2, idx64=134590276, total64=134590216, used64=16,addr64=134575272
bernie: i=3, idx64=-13272, total64=-137246631, used64=134592752,addr64=-13256
bernie: i=4, idx64=-13200, total64=-135048648, used64=0,addr64=0
bernie: i=5, idx64=-13208, total64=-13176, used64=134590312,addr64=5
bernie: i=6, idx64=134590312, total64=134573272, used64=-13160,addr64=10387328
bernie: i=7, idx64=134590312, total64=-13176, used64=134592752,addr64=-13176
bernie: i=8, idx64=4, total64=134573688, used64=0,addr64=0
bernie: i=9, idx64=-13000, total64=10301112, used64=134573272,addr64=134590312
bernie: i=10, idx64=134594655, total64=-13016, used64=-13020,addr64=-134925752
bernie: i=11, idx64=10387328, total64=0, used64=134573272,addr64=134573560
bernie: i=12, idx64=795308655, total64=794978668, used64=-134902188,addr64=6
bernie: i=13, idx64=134592696, total64=134575272, used64=6808360,addr64=7203530
bernie: i=14, idx64=0, total64=0, used64=134565472,addr64=0
bernie: i=15, idx64=134590311, total64=10390632, used64=0,addr64=-12968
bernie: i=16, idx64=134590301, total64=134590312, used64=134573296,addr64=29
bernie: i=17, idx64=-12808, total64=10295986, used64=134573272,addr64=134590312
bernie: i=18, idx64=10387328, total64=7704113, used64=-12840,addr64=72
bernie: i=19, idx64=8006848, total64=8006840, used64=-1,addr64=7999476
bernie: i=20,
Re: ioctl32 support
Bernardo Innocenti wrote: Maybe the fields of RADEONInfoRec should be reworked to use types with a predefined size. Is that right? I've just found out I didn't apply dri-32-compat.patch, which already addresses this problem. Sorry for the noise. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 support
Bernardo Innocenti wrote:
Now libGL works, but something else fails and 32bit
clients fall back to indirect rendering:
After digging around with GDB, I can now elaborate a
bit more.
The call to drmMap() fails because it attempts to
map 0 bytes of memory. We're in r300/radeon_screen.c:radeonCreateScreen():
screen-mmio.handle = dri_priv-registerHandle;
screen-mmio.size = dri_priv-registerSize;
if (drmMap(sPriv-fd,
screen-mmio.handle, screen-mmio.size, screen-mmio.map)) {
dri_priv points to a RADEONInfoRec, which is filled
in by the server side in XF86DRIGetDeviceInfo().
The contents seem to be borked, perhaps because many
fields arn't the same size in the 64bit server side.
The full contents are:
deviceID = 16723,
width = 1400,
height = 1050,
depth = 24,
bpp = 32,
IsPCI = 0,
AGPMode = 8,
frontOffset = 0,
frontPitch = 1408,
backOffset = 23789568,
backPitch = 1408,
depthOffset = 29704192,
depthPitch = 1408,
textureOffset = 35651584,
textureSize = 98566144,
log2TexGran = 21,
registerHandle = 4225761280,
registerSize = 0,
statusHandle = 524288,
statusSize = 0,
gartTexHandle = 378144,
gartTexMapSize = 0,
log2GARTTexGran = 4096,
textureSize = 98566144,
log2TexGran = 21,
registerHandle = 4225761280,
registerSize = 0,
statusHandle = 524288,
statusSize = 0,
gartTexHandle = 378144,
gartTexMapSize = 0,
log2GARTTexGran = 4096,
gartTexOffset = 0,
sarea_priv_offset = 3224379392
Which is perhaps more readable in hex:
deviceID = 0x4153,
width = 0x578,
height = 0x41a,
depth = 0x18,
bpp = 0x20,
IsPCI = 0x0,
AGPMode = 0x8,
frontOffset = 0x0,
frontPitch = 0x580,
backOffset = 0x16b,
backPitch = 0x580,
depthOffset = 0x1c54000,
depthPitch = 0x580,
textureOffset = 0x220,
textureSize = 0x5e0,
log2TexGran = 0x15,
registerHandle = 0xfbe0,
registerSize = 0x0,
statusHandle = 0x8,
statusSize = 0x0,
gartTexHandle = 0xc0101000,
gartTexMapSize = 0x0,
log2GARTTexGran = 0x1000,
textureSize = 0x5e0,
log2TexGran = 0x15,
registerHandle = 0xfbe0,
registerSize = 0x0,
statusHandle = 0x8,
statusSize = 0x0,
gartTexHandle = 0xc0101000,
gartTexMapSize = 0x0,
log2GARTTexGran = 0x1000,
gartTexOffset = 0x0,
sarea_priv_offset = 0xc0302000
Maybe the fields of RADEONInfoRec should be reworked
to use types with a predefined size. Is that right?
--
// Bernardo Innocenti - Develer S.r.l., RD dept.
\X/ http://www.develer.com/
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 support
Donnie Berkholz wrote: Bernardo Innocenti wrote: Is there a reason why this code is not appropriate for merging into the official DRM? You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943. Thank you! I fetched the latest patch and it applied quite nicely to the patched drm tree in r300 CVS, and the modules still work fine with 64bit clients. I had some hard time trying to build a working 32bit libGL.so. GL clients crashed and GDB also crashed while debugging them. Finally, I discovered that ld was linking a few x86_64 objects from libdrm without even issuing an hard error. Damnit, building 32bit stuff in a 64bit is quite tricky! Now libGL works, but something else fails and 32bit clients fall back to indirect rendering: ---cut--- # LIBGL_DEBUG=verbose ./glxgears32 libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen 0) libGL: OpenDriver: trying /usr/local/xorg/lib/modules/dri/r300_dri.so bernie: drmOpen = 0xf7d74738 or 0xf7f6a8d0 bernie: drmOpen=0xf7f6a8d0(NULL,pci::01:00.0) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 libGL error: radeonCreateScreen: drmMap failed libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering 1918 frames in 5.0 seconds = 383.600 FPS ---cut--- -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernardo Innocenti wrote: Hello, I extracted this patch by Egbert Eich from SuSe's kernel source package: http://www.develer.com/drm-ioctl32.patch It allows running 32bit DRI clients on 64bit systems, which is a very common situation due to proprietary games. Is there a reason why this code is not appropriate for merging into the official DRM? You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCuEXmXVaO67S1rtsRAvRlAJ0SrUHjTmZLDoQWyu7zvmSJ7rM1JgCgot5n edJjsxFhyqjcBg+NO6T/42g= =YSGn -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ioctl32 support
Hello, I extracted this patch by Egbert Eich from SuSe's kernel source package: http://www.develer.com/drm-ioctl32.patch It allows running 32bit DRI clients on 64bit systems, which is a very common situation due to proprietary games. Is there a reason why this code is not appropriate for merging into the official DRM? If nobody else is interested, I'd like to try rebasing the patch with the current CVS code. I have near-zero previous experience with it, so I'll probably need help. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
