From: Stephen W. <de...@lu...> - 2004-01-07 23:41:01
|
System: MSI K8T Master2-FAR Dual Opteron Radeon VE Debian 'sid' (32-bit Xfree86) Kernel 2.6.1-rc2-bk1 On Tue, 2004-01-06 at 11:51, Xavier Hienne wrote: > On deb...@li..., Stephen Waters wrote: > > I wonder if this bug could explain my X problems... > > --- > > drivers/char/drm/radeon_state.c: In function `radeon_cp_getparam': > > drivers/char/drm/radeon_state.c:2190: warning: cast from pointer to int= eger of different size > > --- >=20 > Right, a patch seems to exist : > http://function.linuxpower.ca/patches/patch-radeon_state-radeon_cp_getpar= am unfortunately, it did not solve the stability problem. here are the errors I'm getting (this is Debian 'sid' 32-bit Xfree86, just to be clear): ---kern.log--- Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(6) c= md(c0246400){00} arg(085d1320) on /dev/dri/card0 Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(6) c= md(c0246400){00} arg(085d1320) on /dev/dri/card0 Jan 7 00:42:38 localhost kernel: atkbd.c: Unknown key released (translated= set 2, code 0x7a on isa0060/serio0). Jan 7 00:42:38 localhost kernel: atkbd.c: Unknown key released (translated= set 2, code 0x7a on isa0060/serio0). Jan 7 00:42:46 localhost kernel: XFree86[391]: segfault at 000000000000007= 7 rip 00000000085d08ec rsp 00000000ffffd6f4 error 6 --- > BTW, in the same directory, it seems that there are other video and=20 > amd64 related patches (at least one : patch-cpumask_x86_64_pci-gart). If=20 > your problems persist, I suggest you check whether or not they have been=20 > applied in mainstream 2.6 kernels Some of them look like they've been applied already. Also, I'm a little hesitant to apply 6 different cpumask patches. :) Thanks for the help! If there's anything I can do to help that probably won't mess up my fs, let me know. -s |
From: Michel <mi...@da...> - 2004-01-13 00:09:20
|
On Tue, 2004-01-13 at 01:01, Stephen Waters wrote: > On Mon, 2004-01-12 at 16:32, Michel Dänzer wrote: > > On Mon, 2004-01-12 at 20:36, Xavier Hienne wrote: > > > Stephen Waters wrote: > > > > I'm attaching Xfree86 logs for 2.6.1-bk1-amd64 and Debian sid's 32-bit > > > > 2.6.0-k7-smp. > > > > > > > > I still get the segfaults with amd64, but I haven't managed an strace. > > > > Stupid forking keeps kill my strace! :) > > > > 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. Not sure, the VT switch involves a signal, maybe that's it. > Is there something smarter I should do? The best thing is to log in remotely and attach gdb to the server. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Xavier H. <xh...@so...> - 2004-01-13 11:21:30
|
[ I'm sorry to annoy the moderator by CCing to a list that i'm not a member of. Stephen and me are both members of the debian-amd64 mailing list and this discussion occured because he had difficulties while running X on an amd64 kernel and I tried to help him. I'm not at all involved in anything related to graphic chips and my opteron machines are mere servers. Therefore i'm quite reluctant to subscribe, but if it's necessary, tell me, i'll do so for the time this thread is active ] 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 ke...@ke... or kem@XFree86.Org . Gareth > posted to the dri-devel list from ga...@nv... 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 |
From: Michel <mi...@da...> - 2004-01-14 00:38:36
|
On Tue, 2004-01-13 at 12:21, Xavier Hienne wrote: > [ I'm sorry to annoy the moderator by CCing to a list that i'm not a > member of. No worries, I'll deal with it one way or the other. > Michel Dänzer wrote: > > > > Kevin should be reachable via ke...@ke... or kem@XFree86.Org . Gareth > > posted to the dri-devel list from ga...@nv... a (long) while ago. > > The purpose was to inform them of the existence of the patch The MAINTAINERS file in the Linux 2.6.1 source correctly mentions this list as DRM contact. > 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 :-) AFAICT the patch is incorrect. The purpose of that code (which seems unused by the 'normal' DRI drivers BTW, maybe it's for some embedded stuff?) is to return a pointer to the SAREA (shared memory area which contains the hardware lock). The problem is that the ioctl only returns an int - yes, the DRM code isn't 32/64 bit clean yet. :\ > X is a child of gdm, right ? Maybe X is not crashing, but gdm is, The kernel output Stephen posted said otherwise. > - using ltrace instead of strace - because the crash is not necessarily > due to a system call strace certainly isn't useful for tracking this down, but I doubt ltrace is either. You need a debugger to track down crashes. Thanks for your information about how to support both 64 and 32 bit ioctls, I'm sure it'll be helpful for someone who's going to tackle this. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Stephen W. <de...@lu...> - 2004-02-07 04:36:04
|
On Mon, 2004-01-12 at 18:09, Michel D=C3=A4nzer wrote: > On Tue, 2004-01-13 at 01:01, Stephen Waters wrote: > > On Mon, 2004-01-12 at 16:32, Michel D=C3=A4nzer wrote: > > > On Mon, 2004-01-12 at 20:36, Xavier Hienne wrote:=20 > > > > Stephen Waters wrote: > > > > > I'm attaching Xfree86 logs for 2.6.1-bk1-amd64 and Debian sid's 3= 2-bit > > > > > 2.6.0-k7-smp. > > > > >=20 > > > > > I still get the segfaults with amd64, but I haven't managed an st= race. > > > > > Stupid forking keeps kill my strace! :) > > >=20 > > > What forking, BTW? The X server doesn't fork, does it? > >=20 > > I can't figure out why else strace would just stop logging and exit > > normally... > >=20 > > 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. >=20 > Not sure, the VT switch involves a signal, maybe that's it. >=20 > > Is there something smarter I should do? >=20 > The best thing is to log in remotely and attach gdb to the server. I just tried this. Here's what happens: # gdb (gdb) attach $pid_of_X Loading Symbols... blah blah (gdb) continue Segmentation Fault So, I can't get you a backtrace... probably due to 32 vs 64 -bitness, but who knows? What alternatives do I have? This is gdb 6.0 in Debian 'sid'... Thanks! -s |
From: Michel <mi...@da...> - 2004-02-07 11:08:35
|
On Sat, 2004-02-07 at 03:55, Stephen Waters wrote: > On Mon, 2004-01-12 at 18:09, Michel Dänzer wrote: > > > > The best thing is to log in remotely and attach gdb to the server. > > I just tried this. Here's what happens: > > # gdb > (gdb) attach $pid_of_X > Loading Symbols... blah blah FWIW, when I attach gdb to a process, I usually start it with the corresponding binary, e.g. gdb XFree86 > (gdb) continue > Segmentation Fault Is this gdb segfaulting? If so, that's a gdb bug which should be reported. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Stephen W. <de...@lu...> - 2004-02-07 16:28:57
|
On Sat, 2004-02-07 at 04:53, Michel D=C3=A4nzer wrote: > On Sat, 2004-02-07 at 03:55, Stephen Waters wrote: > > On Mon, 2004-01-12 at 18:09, Michel D=C3=A4nzer wrote: > > >=20 > > > The best thing is to log in remotely and attach gdb to the server. > >=20 > > I just tried this. Here's what happens: > >=20 > > # gdb > > (gdb) attach $pid_of_X > > Loading Symbols... blah blah >=20 > FWIW, when I attach gdb to a process, I usually start it with the > corresponding binary, e.g. >=20 > gdb XFree86 I tried that, but X detaches itself from the running gdb session whenever I start a WM so I have to use "attach PID". I have to start a WM, because the problem doesn't manifest itself until I start one. Enlightenment is a good example b/c of its rich feature set... really taxes the graphics libs, etc. But, even twm will crash with some effort so I don't think it's localized to Enlightenment. > > (gdb) continue > > Segmentation Fault >=20 > Is this gdb segfaulting? If so, that's a gdb bug which should be > reported. It could be a kernel bug... there's a patch between 2.6.0 and 2.6.3-rc1 which fixes some gdb problem on amd64. Will let you and/or gdb team know if I manage to get 2.6.3-rc1 (or higher) up and running. -s |
From: Michel <mi...@da...> - 2004-01-10 17:30:52
|
On Thu, 2004-01-08 at 00:40, Stephen Waters wrote: > System: > MSI K8T Master2-FAR > Dual Opteron > Radeon VE > Debian 'sid' (32-bit Xfree86) > Kernel 2.6.1-rc2-bk1 Have you tried the DRI snapshot packages described in http://dri.sourceforge.net/snapshots/README.Debian yet? > On Tue, 2004-01-06 at 11:51, Xavier Hienne wrote: > > On deb...@li..., Stephen Waters wrote: > > > I wonder if this bug could explain my X problems... > > > --- > > > drivers/char/drm/radeon_state.c: In function `radeon_cp_getparam': > > > drivers/char/drm/radeon_state.c:2190: warning: cast from pointer to integer of different size > > > --- > > > > Right, a patch seems to exist : > > http://function.linuxpower.ca/patches/patch-radeon_state-radeon_cp_getparam > > unfortunately, it did not solve the stability problem. What stability problem? Note that the getparam ioctl is only used by the 3D driver. > here are the errors I'm getting (this is Debian 'sid' 32-bit Xfree86, > just to be clear): > > ---kern.log--- > Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(6) cmd(c0246400){00} arg(085d1320) on /dev/dri/card0 > Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(6) cmd(c0246400){00} arg(085d1320) on /dev/dri/card0 AFAICT this is the DRM_IOCTL_VERSION ioctl, odd that it would be missing... I wonder if the ioctls need special treatment for 32 bit apps? > Jan 7 00:42:46 localhost kernel: XFree86[391]: segfault at 0000000000000077 rip 00000000085d08ec rsp 00000000ffffd6f4 error 6 If this is a 'normal' X server segfault, you should try to get a backtrace, e.g. using the xserver-xfree86-dbg package. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Stephen W. <de...@lu...> - 2004-01-12 04:53:30
|
On Sat, 2004-01-10 at 11:30, Michel D=C3=A4nzer wrote:=20 > On Thu, 2004-01-08 at 00:40, Stephen Waters wrote: > > System: > > MSI K8T Master2-FAR > > Dual Opteron > > Radeon VE > > Debian 'sid' (32-bit Xfree86) > > Kernel 2.6.1-rc2-bk1 >=20 > Have you tried the DRI snapshot packages described in > http://dri.sourceforge.net/snapshots/README.Debian yet? not yet. If this latest kernel (2.6.1-bk1) doesn't work, I'll give those patches a shot.=20 > What stability problem? Note that the getparam ioctl is only used by the > 3D driver. It crashed if you did much of anything. :) Sometimes gdm would crash, sometimes my start-up apps will load and then it will crash.=20 Currently, I'm writing this on 2.6.1-bk1, AMD64. It seems to work mostly, but Enlightenment crashes fairly often. I kinda wonder how hardcore Rasterman got with the asm in Imlib... The big difference is I compiled Linux DRI radeon as a module this time instead of statically. That seemed to clear up a good bit of the stability. I still get the ioctl32 error, though. > > here are the errors I'm getting (this is Debian 'sid' 32-bit Xfree86, > > just to be clear): > >=20 > > --kern.log-- > > Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(= 6) cmd(c0246400){00} arg(085d1320) on /dev/dri/card0 > > Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(= 6) cmd(c0246400){00} arg(085d1320) on /dev/dri/card0 >=20 > AFAICT this is the DRM_IOCTL_VERSION ioctl, odd that it would be > missing... I wonder if the ioctls need special treatment for 32 bit > apps? Xavier Hienne thinks: -- I always thought ioctl numbers would be constants among archs but DRM=20 ioctl numbers depend on the architecture. Here, ioctl c0246400 is=20 DRM_IOCTL_VERSION, but only on a 32bit arch because the size of a=20 structure is hardcoded into this number (bits 16 to 29 - see comment in=20 /usr/src/linux/include/asm/ioctl.h). The pb is that this structure=20 contains 3 pointers, thus its size goes from 0x024 on a 32 bit arch, to=20 0x030 (my guess) on a 64 bit arch. -- > > Jan 7 00:42:46 localhost kernel: XFree86[391]: segfault at 00000000000= 00077 rip 00000000085d08ec rsp 00000000ffffd6f4 error 6 >=20 > If this is a 'normal' X server segfault, you should try to get a > backtrace, e.g. using the xserver-xfree86-dbg package. i'll get you an 'strace -p' when I can... FYI. Cheers and thanks for looking at this, -s |
From: Stephen W. <de...@lu...> - 2004-01-12 05:47:40
|
I'm attaching Xfree86 logs for 2.6.1-bk1-amd64 and Debian sid's 32-bit 2.6.0-k7-smp. I still get the segfaults with amd64, but I haven't managed an strace. Stupid forking keeps kill my strace! :) -s |
From: Xavier H. <xh...@so...> - 2004-01-12 19:36:32
|
Stephen Waters wrote: > I'm attaching Xfree86 logs for 2.6.1-bk1-amd64 and Debian sid's 32-bit > 2.6.0-k7-smp. > > I still get the segfaults with amd64, but I haven't managed an strace. > Stupid forking keeps kill my strace! :) 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. For the moment, and until x86_64 DRM modules support 32 bit ioctls, you have two choices: either test the amd64 version of XFree86 or stay with the 32 bit version without DRI. Regards, Xavier PS: Michel, since you're involve in DRM development, i'd like to bring to your attention that two email addresses (given in several radeon drm files) are obsolete : according to Va Software postmaster, Kevin E. Martin <ma...@va...> and Gareth Hughes <ga...@va...> left VaLinux more than 2 years ago. |
From: Michel <mi...@da...> - 2004-01-12 22:32:41
|
On Mon, 2004-01-12 at 20:36, Xavier Hienne wrote: > Stephen Waters wrote: > > I'm attaching Xfree86 logs for 2.6.1-bk1-amd64 and Debian sid's 32-bit > > 2.6.0-k7-smp. > > > > I still get the segfaults with amd64, but I haven't managed an strace. > > Stupid forking keeps kill my strace! :) What forking, BTW? The X server doesn't fork, does it? > 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. AFAIK Andrew Morton recently updated the DRM in his tree, maybe that's already in 2.6.1-bk1.amd64 and breaks the relatively old X server even more? > [...] until x86_64 DRM modules support 32 bit ioctls [...] What does the DRM have to do to support them? > PS: Michel, since you're involve in DRM development, i'd like to bring > to your attention that two email addresses (given in several radeon drm > files) are obsolete : according to Va Software postmaster, Kevin E. > Martin <ma...@va...> and Gareth Hughes <ga...@va...> left > VaLinux more than 2 years ago. Kevin should be reachable via ke...@ke... or kem@XFree86.Org . Gareth posted to the dri-devel list from ga...@nv... a (long) while ago. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Kevin E M. <ma...@xf...> - 2004-01-12 23:38:40
|
On Mon, Jan 12, 2004 at 11:32:37PM +0100, Michel Dänzer wrote: > On Mon, 2004-01-12 at 20:36, Xavier Hienne wrote: > > PS: Michel, since you're involve in DRM development, i'd like to bring > > to your attention that two email addresses (given in several radeon drm > > files) are obsolete : according to Va Software postmaster, Kevin E. > > Martin <ma...@va...> and Gareth Hughes <ga...@va...> left > > VaLinux more than 2 years ago. > > Kevin should be reachable via .... The best e-mail address is <ma...@xf...> for things related to XFree86/DRI/DRM. If you want to change my e-mail address in the DRM code, please feel free to do so. Thanks, Kevin |
From: Stephen W. <de...@lu...> - 2004-01-13 00:02:07
|
On Mon, 2004-01-12 at 16:32, Michel D=C3=A4nzer wrote: > On Mon, 2004-01-12 at 20:36, Xavier Hienne wrote:=20 > > Stephen Waters wrote: > > > I'm attaching Xfree86 logs for 2.6.1-bk1-amd64 and Debian sid's 32-bi= t > > > 2.6.0-k7-smp. > > >=20 > > > I still get the segfaults with amd64, but I haven't managed an strace= . > > > Stupid forking keeps kill my strace! :) >=20 > 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. Is there something smarter I should do? > Not sure, DRI initialisation seems to succeed with the older kernel. > AFAIK Andrew Morton recently updated the DRM in his tree, maybe that's > already in 2.6.1-bk1.amd64 and breaks the relatively old X server even > more? Well, currently, 2.6.0 32-bit Debian doesn't even work with DRI... you can check my X log I sent to the list. It gets further, but it doesn't like the 2.6 agpgart for some reason. > > [...] until x86_64 DRM modules support 32 bit ioctls [...] >=20 > 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 hack Perl and SQL, though, so I HAVE NO CLUE! ;) Let me know about the best way to strace X and I'll get you a more useful dump. Cheers, -s |
From: Ryan U. <nem...@ic...> - 2004-01-13 16:53:50
|
On Mon, Jan 12, 2004 at 06:01:42PM -0600, Stephen Waters wrote: >=20 >=20 > I can't figure out why else strace would just stop logging and exit > normally... >=20 > 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. >=20 > Is there something smarter I should do? If it really is forking somehow, using -f on strace should follow the forks. But I have a feeling that isn't what is really going on. --=20 Ryan Underwood, <ne...@ic...> |
From: Stephen W. <de...@lu...> - 2004-01-13 00:07:31
|
> For the moment, and until x86_64 DRM modules support 32 bit ioctls, you=20 > have two choices: either test the amd64 version of XFree86 or stay with=20 > the 32 bit version without DRI. well, the 32-bit version minus DRI is still flaky on AMD64. It's not really usable as it crashes pretty easily. I recognize dri-devel is not the place to necessarily discuss non-DRI X problems, but I bet DRI team would be interested in agpgart/DRI not working on plain 32-bit kernel and X architecture. If y'all can suggest the best way to get an X strace, I'll supply it. :) -s |
From: Michel <mi...@da...> - 2004-01-12 12:15:47
|
On Mon, 2004-01-12 at 05:53, Stephen Waters wrote: > On Sat, 2004-01-10 at 11:30, Michel Dänzer wrote: > > On Thu, 2004-01-08 at 00:40, Stephen Waters wrote: > > > What stability problem? Note that the getparam ioctl is only used by the > > 3D driver. > > It crashed if you did much of anything. :) Sometimes gdm would crash, That would be a gdm bug. Do you mean the X server crashes while gdm comes up? > Currently, I'm writing this on 2.6.1-bk1, AMD64. It seems to work > mostly, Maybe because the DRI isn't enabled? :\ > > > Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(6) cmd(c0246400){00} arg(085d1320) on /dev/dri/card0 > > > Jan 7 00:42:37 localhost kernel: ioctl32(XFree86:391): Unknown cmd fd(6) cmd(c0246400){00} arg(085d1320) on /dev/dri/card0 > > > > AFAICT this is the DRM_IOCTL_VERSION ioctl, odd that it would be > > missing... I wonder if the ioctls need special treatment for 32 bit > > apps? > > Xavier Hienne thinks: > -- > I always thought ioctl numbers would be constants among archs but DRM > ioctl numbers depend on the architecture. Here, ioctl c0246400 is > DRM_IOCTL_VERSION, but only on a 32bit arch because the size of a > structure is hardcoded into this number (bits 16 to 29 - see comment in > /usr/src/linux/include/asm/ioctl.h). The pb is that this structure > contains 3 pointers, thus its size goes from 0x024 on a 32 bit arch, to > 0x030 (my guess) on a 64 bit arch. Yep, so I guess the DRM would indeed have to treat the 32 bit ioctls specially. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |