Michel Dänzer wrote: > >>The (EE) line in XFree86.0.log_2.6.1-bk1.amd64 indicates that DRM >>initialization failed. I guess it's still because of ioctl number >>incompatibilities between 32 bit XFree86 and the 64 bit kernel module. > > > Not sure, DRI initialisation seems to succeed with the older kernel.
My understanding is that the older kernel is a 32 bit one, whereas the newer kernel is a 64 bit one. Incompatibilities arise during ioctl calls only when using 32 bit XFree86 with 64 bit DRM modules.
[...]
Kevin should be reachable via [EMAIL PROTECTED] or [EMAIL PROTECTED] . Gareth posted to the dri-devel list from [EMAIL PROTECTED] a (long) while ago.
The purpose was to inform them of the existence of the patch
http://function.linuxpower.ca/patches/patch-radeon_state-radeon_cp_getparam
that, at least, seems to solve a warning that got Stephen while compiling the radeon drm module. Now you know :-)
Stephen Waters wrote:
What forking, BTW? The X server doesn't fork, does it?
I can't figure out why else strace would just stop logging and exit normally...
here's my workflow: 1) /etc/init.d/gdm restart 2) ctrl+alt+f1 to get back to terminal 3) ps x |grep X 4) strace -p pid_of_X 5) alt+f7 6) log into gdm 7) <crash> 8) back to VT1 where I notice that strace exited normally without any useful information leading me to believe that it exits at login due to some forking thing.
X is a child of gdm, right ? Maybe X is not crashing, but gdm is, and therefore its childs terminate normally. That would explain why you see nothing special when stracing X.
Is there something smarter I should do?
Some suggestions of mine:
- tracing gdm instead of X
- using ltrace instead of strace - because the crash is not necessarily due to a system call
- post-mortem analysis of a core dumped by gdm (a debugger friendly version of gdm would be welcome since gdm might have been stripped)
[...]
[...] until x86_64 DRM modules support 32 bit ioctls [...]
What does the DRM have to do to support them?
Xavier's the one who looked at it, but it's my guess that the embedded pointers need some massaging.
I'm not a kernel developer. I assume 64 bit DRM modules should support both 32 bit and 64 bit ioctls. First for each 64 bit ioctl number, you would define a corresponding 32 bit ioctl number in the x86_64 branch.
Then, i guess most ioctls might share common code and would be simple to deal with. But others would need some wrapping so that the actual 64 bit ioctl would be called with data coming from or going to a 32 bit userspace.
My understanding of the kernel is quite limited, but I guess this wrapping would roughly involve some or all of the following steps (here i assume that the 3rd argument to ioctl is a pointer to a structure that differs among 32 bit and 64 bit environments) :
- get data from userspace into a local 32 bit structure
- fill the corresponding 64 bit structure with these data
- call the actual 64 bit ioctl
- fill the local 32 bit structure with the 64 bit structure's data
- copy the 32 bit structure into userspace
32 bit backward compatibility in ioctl calls is a pb that has already been dealt with in other parts of the kernel. As a start, see for example:
/usr/src/linux/include/linux/ioctl32.h
/usr/src/linux/fs/compat.c
/usr/src/linux/include/asm-x86_64/compat.h
Regards,
Xavier
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
