Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Ryan Richter wrote: > > I had heard something previously about i965_dri.so maybe getting > miscompiled, but I hadn't followed up on it until now. I rebuilt it > with an older gcc, and now it's all working great! Sorry for the wild > goose chase. > It was probably me. I had the same experience, except that I recompiled using the system compiler. Possibly it got updated between the distro compilation of the driver and my own. So I don't think there's a need to try to reproduce it as it was probably fixed in gcc already. https://bugs.freedesktop.org/show_bug.cgi?id=8384 -- error compiling committee.c: too many arguments to function - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Tue, Oct 24, 2006 at 02:21:42PM +0200, Avi Kivity wrote: > Ryan Richter wrote: > > > >I had heard something previously about i965_dri.so maybe getting > >miscompiled, but I hadn't followed up on it until now. I rebuilt it > >with an older gcc, and now it's all working great! Sorry for the wild > >goose chase. > > > > It was probably me. I had the same experience, except that I recompiled > using the system compiler. Possibly it got updated between the distro > compilation of the driver and my own. > > So I don't think there's a need to try to reproduce it as it was > probably fixed in gcc already. > > https://bugs.freedesktop.org/show_bug.cgi?id=8384 It worked for me when I recompiled with -fno-strict-aliasing (or with an older gcc - 3.4 rather than 4.1). -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Fri, Oct 20, 2006 at 06:51:01PM +0100, Keith Whitwell wrote: > Ryan Richter wrote: > >On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote: > >>Ryan Richter wrote: > >>>On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: > >>All of your other wierd problems, like the assert failures, etc, make me > >>wonder if there just hasn't been some sort of build problem that can > >>only be resolved by clearing it out and restarting. > >> > >>It wouldn't hurt to just nuke your current Mesa and libdrm builds and > >>start from scratch - you'll probably have to do that to get debug > >>symbols for gdb anyway. > > > >I had heard something previously about i965_dri.so maybe getting > >miscompiled, but I hadn't followed up on it until now. I rebuilt it > >with an older gcc, and now it's all working great! Sorry for the wild > >goose chase. > > Out of interest, can you try again with the original GCC and see if the > problem comes back? Which versions of GCC are you using? The two gcc versions are the 4.1 (miscompiles) and 3.4 (OK) from Debian unstable. I had originally compiled it myself with gcc-4.1 because the Debian libgl1-mesa-dri package didn't build i965_dri.so until I submitted a build patch to them to have it built. They released a new package a few days ago with i965_dri.so included, presumably built with the same gcc-4.1, the default cc on Debian unstable. I had exactly the same problems with my own version and theirs. I rebuilt it again today with CC=gcc-3.4 and now everything works great. I saved a copy of the old i965_dri.so, so I can verify in the next few days that replacing it breaks things again. Let me know if you want copies of these files to examine. -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Ryan Richter wrote: > On Fri, Oct 20, 2006 at 06:51:01PM +0100, Keith Whitwell wrote: >> Ryan Richter wrote: >>> On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote: Ryan Richter wrote: > On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: All of your other wierd problems, like the assert failures, etc, make me wonder if there just hasn't been some sort of build problem that can only be resolved by clearing it out and restarting. It wouldn't hurt to just nuke your current Mesa and libdrm builds and start from scratch - you'll probably have to do that to get debug symbols for gdb anyway. >>> I had heard something previously about i965_dri.so maybe getting >>> miscompiled, but I hadn't followed up on it until now. I rebuilt it >>> with an older gcc, and now it's all working great! Sorry for the wild >>> goose chase. >> Out of interest, can you try again with the original GCC and see if the >> problem comes back? Which versions of GCC are you using? > > The two gcc versions are the 4.1 (miscompiles) and 3.4 (OK) from Debian > unstable. I had originally compiled it myself with gcc-4.1 because the > Debian libgl1-mesa-dri package didn't build i965_dri.so until I > submitted a build patch to them to have it built. They released a new > package a few days ago with i965_dri.so included, presumably built with > the same gcc-4.1, the default cc on Debian unstable. > > I had exactly the same problems with my own version and theirs. I > rebuilt it again today with CC=gcc-3.4 and now everything works great. > I saved a copy of the old i965_dri.so, so I can verify in the next few > days that replacing it breaks things again. Let me know if you want > copies of these files to examine. Sure, email me the 4.1 version offline. I'll also see about installing 4.1 here. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Ryan Richter wrote: > On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote: >> Ryan Richter wrote: >>> On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: This is all a little confusing as the driver doesn't really use that path in normal operation except for a single command - MI_FLUSH, which is shared between the architectures. In normal operation the hardware does the validation for us for the bulk of the command stream. If there were missing functionality in that ioctl, it would be failing everywhere, not just in this one case. I guess the questions I'd have are - did the driver work before the kernel upgrade? - what path in userspace is seeing you end up in this ioctl? - and like Keith, what commands are you seeing? The final question is interesting not because we want to extend the ioctl to cover those, but because it will give a clue how you ended up there in the first place. >>> Here's a list of all the failing commands I've seen so far: >>> >>> 3a440003 >>> d70003 >>> 2d010003 >>> e5b90003 >>> 2e730003 >>> 8d8c0003 >>> c10003 >>> d90003 >>> be0003 >>> 1e3f0003 >> Ryan, >> >> Those don't look like any commands I can recognize. I'm still confused >> how you got onto this ioctl in the first place - it seems like something >> pretty fundamental is going wrong somewhere. What would be useful to me >> is if you can use GDB on your application and get a stacktrace for how >> you end up in this ioctl in the cases where it is failing? >> >> Additionally, if you're comfortable doing this, it would be helpful to >> see all the arguments that userspace thinks its sending to the ioctl, >> compared to what the kernel ends up thinking it has to validate. There >> shouldn't ever be more than two dwords being validated at a time, and >> they should look more or less exactly like {0x0203, 0}, and be >> emitted from bmSetFence(). >> >> All of your other wierd problems, like the assert failures, etc, make me >> wonder if there just hasn't been some sort of build problem that can >> only be resolved by clearing it out and restarting. >> >> It wouldn't hurt to just nuke your current Mesa and libdrm builds and >> start from scratch - you'll probably have to do that to get debug >> symbols for gdb anyway. > > I had heard something previously about i965_dri.so maybe getting > miscompiled, but I hadn't followed up on it until now. I rebuilt it > with an older gcc, and now it's all working great! Sorry for the wild > goose chase. Out of interest, can you try again with the original GCC and see if the problem comes back? Which versions of GCC are you using? Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote: > Ryan Richter wrote: > >On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: > >>This is all a little confusing as the driver doesn't really use that > >>path in normal operation except for a single command - MI_FLUSH, which > >>is shared between the architectures. In normal operation the hardware > >>does the validation for us for the bulk of the command stream. If there > >> were missing functionality in that ioctl, it would be failing > >>everywhere, not just in this one case. > >> > >>I guess the questions I'd have are > >>- did the driver work before the kernel upgrade? > >>- what path in userspace is seeing you end up in this ioctl? > >>- and like Keith, what commands are you seeing? > >> > >>The final question is interesting not because we want to extend the > >>ioctl to cover those, but because it will give a clue how you ended up > >>there in the first place. > > > >Here's a list of all the failing commands I've seen so far: > > > >3a440003 > >d70003 > >2d010003 > >e5b90003 > >2e730003 > >8d8c0003 > >c10003 > >d90003 > >be0003 > >1e3f0003 > > Ryan, > > Those don't look like any commands I can recognize. I'm still confused > how you got onto this ioctl in the first place - it seems like something > pretty fundamental is going wrong somewhere. What would be useful to me > is if you can use GDB on your application and get a stacktrace for how > you end up in this ioctl in the cases where it is failing? > > Additionally, if you're comfortable doing this, it would be helpful to > see all the arguments that userspace thinks its sending to the ioctl, > compared to what the kernel ends up thinking it has to validate. There > shouldn't ever be more than two dwords being validated at a time, and > they should look more or less exactly like {0x0203, 0}, and be > emitted from bmSetFence(). > > All of your other wierd problems, like the assert failures, etc, make me > wonder if there just hasn't been some sort of build problem that can > only be resolved by clearing it out and restarting. > > It wouldn't hurt to just nuke your current Mesa and libdrm builds and > start from scratch - you'll probably have to do that to get debug > symbols for gdb anyway. I had heard something previously about i965_dri.so maybe getting miscompiled, but I hadn't followed up on it until now. I rebuilt it with an older gcc, and now it's all working great! Sorry for the wild goose chase. Thanks, -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Ryan Richter wrote: > On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: >> This is all a little confusing as the driver doesn't really use that >> path in normal operation except for a single command - MI_FLUSH, which >> is shared between the architectures. In normal operation the hardware >> does the validation for us for the bulk of the command stream. If there >> were missing functionality in that ioctl, it would be failing >> everywhere, not just in this one case. >> >> I guess the questions I'd have are >> - did the driver work before the kernel upgrade? >> - what path in userspace is seeing you end up in this ioctl? >> - and like Keith, what commands are you seeing? >> >> The final question is interesting not because we want to extend the >> ioctl to cover those, but because it will give a clue how you ended up >> there in the first place. > > Here's a list of all the failing commands I've seen so far: > > 3a440003 > d70003 > 2d010003 > e5b90003 > 2e730003 > 8d8c0003 > c10003 > d90003 > be0003 > 1e3f0003 Ryan, Those don't look like any commands I can recognize. I'm still confused how you got onto this ioctl in the first place - it seems like something pretty fundamental is going wrong somewhere. What would be useful to me is if you can use GDB on your application and get a stacktrace for how you end up in this ioctl in the cases where it is failing? Additionally, if you're comfortable doing this, it would be helpful to see all the arguments that userspace thinks its sending to the ioctl, compared to what the kernel ends up thinking it has to validate. There shouldn't ever be more than two dwords being validated at a time, and they should look more or less exactly like {0x0203, 0}, and be emitted from bmSetFence(). All of your other wierd problems, like the assert failures, etc, make me wonder if there just hasn't been some sort of build problem that can only be resolved by clearing it out and restarting. It wouldn't hurt to just nuke your current Mesa and libdrm builds and start from scratch - you'll probably have to do that to get debug symbols for gdb anyway. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: > This is all a little confusing as the driver doesn't really use that > path in normal operation except for a single command - MI_FLUSH, which > is shared between the architectures. In normal operation the hardware > does the validation for us for the bulk of the command stream. If there > were missing functionality in that ioctl, it would be failing > everywhere, not just in this one case. > > I guess the questions I'd have are > - did the driver work before the kernel upgrade? > - what path in userspace is seeing you end up in this ioctl? > - and like Keith, what commands are you seeing? > > The final question is interesting not because we want to extend the > ioctl to cover those, but because it will give a clue how you ended up > there in the first place. Here's a list of all the failing commands I've seen so far: 3a440003 d70003 2d010003 e5b90003 2e730003 8d8c0003 c10003 d90003 be0003 1e3f0003 -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Wed, Oct 18, 2006 at 06:27:42AM +0800, Keith Packard wrote: > On Tue, 2006-10-17 at 13:40 -0400, Ryan Richter wrote: > > > So do I want something like > > > > > > static int do_validate_cmd(int cmd) > > { > > return 1; > > } > > > > in i915_dma.c? > > that will certainly avoid any checks. Another alternative is to printk > the cmd which fails validation so we can see what needs adding here. With just the above, running a GL client (even glxinfo) locks up the display such that it can't be recovered without a reboot. It doesn't kill the machine, though. What looks like a 64x64 block of garbage appears on the screen. The kernel says [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 0 emitted: 2 If instead I change the validate_cmd function to: static int validate_cmd(int cmd) { int ret = do_validate_cmd(cmd); if(!ret) printk("validate_cmd( %x ): %d\n", cmd, ret); return 1; } I get basically the same behavior, but different output: validate_cmd( 1e3f0003 ): 0 validate_cmd( 1e3f0003 ): 0 validate_cmd( d90003 ): 0 validate_cmd( d90003 ): 0 validate_cmd( d70003 ): 0 validate_cmd( d90003 ): 0 validate_cmd( d90003 ): 0 validate_cmd( d90003 ): 0 validate_cmd( d90003 ): 0 validate_cmd( 8d8c0003 ): 0 validate_cmd( d70003 ): 0 [drm:i915_batchbuffer] *ERROR* i915_batchbuffer called without lock held Thanks, -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Sat, Oct 14, 2006 at 11:15:23AM -0700, Keith Packard wrote: > On Fri, 2006-10-13 at 15:45 -0400, Ryan Richter wrote: > > I have a new Intel 965G board, and I'm trying to get DRI working. > > Direct rendering is enabled, but all GL programs crash immediately. > > The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the > > kernel says: > > > > [drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed > > The 915 DRM validates commands sent to the card from the application to > ensure they aren't directing the card to access memory outside of the > graphics area. At present the module validates only 915/945 commands > correctly and the 965 uses slightly different commands. I haven't walked > over the entire GL library, but it seems possible that this error is > being caused by the mis-validation of the command stream. We need to > update the DRM driver to reflect the new commands, but in the meanwhile, > you might try disabling the validation in the kernel (which will expose > your system to a local root compromise) and seeing if that doesn't > eliminate this message. So do I want something like static int do_validate_cmd(int cmd) { return 1; } in i915_dma.c? Thanks, -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Does the DRM git tree work would also be interesting,... I haven't merged up Michel's drawable/blank changes for 2.6.19 as they were much too new for it, but do we have a backwards compat issue perhaps or something similiar? Dave. On Wed, 18 Oct 2006, Keith Whitwell wrote: > This is all a little confusing as the driver doesn't really use that > path in normal operation except for a single command - MI_FLUSH, which > is shared between the architectures. In normal operation the hardware > does the validation for us for the bulk of the command stream. If there > were missing functionality in that ioctl, it would be failing > everywhere, not just in this one case. > > I guess the questions I'd have are > - did the driver work before the kernel upgrade? > - what path in userspace is seeing you end up in this ioctl? > - and like Keith, what commands are you seeing? > > The final question is interesting not because we want to extend the > ioctl to cover those, but because it will give a clue how you ended up > there in the first place. > > Keith > > Keith Packard wrote: >> On Tue, 2006-10-17 at 13:40 -0400, Ryan Richter wrote: >> >>> So do I want something like >>> >>> >>> static int do_validate_cmd(int cmd) >>> { >>> return 1; >>> } >>> >>> in i915_dma.c? >> >> that will certainly avoid any checks. Another alternative is to printk >> the cmd which fails validation so we can see what needs adding here. >> >> >> >> >> >> - >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> >> >> >> >> -- >> ___ >> Dri-devel mailing list >> Dri-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dri-devel > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
This is all a little confusing as the driver doesn't really use that path in normal operation except for a single command - MI_FLUSH, which is shared between the architectures. In normal operation the hardware does the validation for us for the bulk of the command stream. If there were missing functionality in that ioctl, it would be failing everywhere, not just in this one case. I guess the questions I'd have are - did the driver work before the kernel upgrade? - what path in userspace is seeing you end up in this ioctl? - and like Keith, what commands are you seeing? The final question is interesting not because we want to extend the ioctl to cover those, but because it will give a clue how you ended up there in the first place. Keith Keith Packard wrote: > On Tue, 2006-10-17 at 13:40 -0400, Ryan Richter wrote: > >> So do I want something like >> >> >> static int do_validate_cmd(int cmd) >> { >> return 1; >> } >> >> in i915_dma.c? > > that will certainly avoid any checks. Another alternative is to printk > the cmd which fails validation so we can see what needs adding here. > > > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > > > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Tue, 2006-10-17 at 13:40 -0400, Ryan Richter wrote: > So do I want something like > > > static int do_validate_cmd(int cmd) > { > return 1; > } > > in i915_dma.c? that will certainly avoid any checks. Another alternative is to printk the cmd which fails validation so we can see what needs adding here. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Fri, 2006-10-13 at 15:45 -0400, Ryan Richter wrote: > I have a new Intel 965G board, and I'm trying to get DRI working. > Direct rendering is enabled, but all GL programs crash immediately. > The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the > kernel says: > > [drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed The 915 DRM validates commands sent to the card from the application to ensure they aren't directing the card to access memory outside of the graphics area. At present the module validates only 915/945 commands correctly and the 965 uses slightly different commands. I haven't walked over the entire GL library, but it seems possible that this error is being caused by the mis-validation of the command stream. We need to update the DRM driver to reflect the new commands, but in the meanwhile, you might try disabling the validation in the kernel (which will expose your system to a local root compromise) and seeing if that doesn't eliminate this message. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Ryan Richter wrote: > > I have a new Intel 965G board, and I'm trying to get DRI working. > Direct rendering is enabled, but all GL programs crash immediately. > The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the > kernel says: > > [drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed > I had the same problem. Recompiling i965_dri.so in order to insert debugging code "fixed" it for me. It continued working after a mesa package update so I assumed it was a miscompilation. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Sat, 2006-10-14 at 09:55 +0100, Keith Whitwell wrote: > Your drm module is out of date. Since the reporter is using the latest brand spanking new kernel, that is highly unlikely unless something else in the software universe is assuming newer-than-brand-spanking-new. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Arjan van de Ven wrote: > On Sat, 2006-10-14 at 09:55 +0100, Keith Whitwell wrote: >> Your drm module is out of date. > > > Since the reporter is using the latest brand spanking new kernel, that > is highly unlikely unless something else in the software universe is > assuming newer-than-brand-spanking-new. Heh. I missed that in the title line. I'll retire quietly... Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
Your drm module is out of date. Keith Ryan Richter wrote: > I have a new Intel 965G board, and I'm trying to get DRI working. > Direct rendering is enabled, but all GL programs crash immediately. > The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the > kernel says: > > [drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed > > Additionally, glxinfo says (in addition to its normal output): > > glxinfo: bufmgr_fake.c:1245: bmReleaseBuffers: Assertion `intel->locked' > failed. > > This is with 2.6.19-rc2 (and -rc1). Here's a .config and dmesg: > > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.19-rc2 > # Fri Oct 13 13:42:19 2006 > # > CONFIG_X86_64=y > CONFIG_64BIT=y > CONFIG_X86=y > CONFIG_ZONE_DMA32=y > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_SEMAPHORE_SLEEPERS=y > CONFIG_MMU=y > CONFIG_RWSEM_GENERIC_SPINLOCK=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_X86_CMPXCHG=y > CONFIG_EARLY_PRINTK=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_IOMAP=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_ARCH_POPULATES_NODE_MAP=y > CONFIG_DMI=y > CONFIG_AUDIT_ARCH=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > > # > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > > # > # General setup > # > CONFIG_LOCALVERSION="" > CONFIG_LOCALVERSION_AUTO=y > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > # CONFIG_IPC_NS is not set > # CONFIG_POSIX_MQUEUE is not set > # CONFIG_BSD_PROCESS_ACCT is not set > # CONFIG_TASKSTATS is not set > # CONFIG_UTS_NS is not set > # CONFIG_AUDIT is not set > # CONFIG_IKCONFIG is not set > # CONFIG_CPUSETS is not set > CONFIG_RELAY=y > CONFIG_INITRAMFS_SOURCE="" > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_SYSCTL=y > # CONFIG_EMBEDDED is not set > CONFIG_UID16=y > # CONFIG_SYSCTL_SYSCALL is not set > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > CONFIG_SHMEM=y > CONFIG_SLAB=y > CONFIG_VM_EVENT_COUNTERS=y > CONFIG_RT_MUTEXES=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > # CONFIG_SLOB is not set > > # > # Loadable module support > # > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > # CONFIG_MODULE_FORCE_UNLOAD is not set > # CONFIG_MODVERSIONS is not set > # CONFIG_MODULE_SRCVERSION_ALL is not set > # CONFIG_KMOD is not set > CONFIG_STOP_MACHINE=y > > # > # Block layer > # > CONFIG_BLOCK=y > CONFIG_LBD=y > # CONFIG_BLK_DEV_IO_TRACE is not set > # CONFIG_LSF is not set > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_AS=y > CONFIG_IOSCHED_DEADLINE=y > CONFIG_IOSCHED_CFQ=y > CONFIG_DEFAULT_AS=y > # CONFIG_DEFAULT_DEADLINE is not set > # CONFIG_DEFAULT_CFQ is not set > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="anticipatory" > > # > # Processor type and features > # > CONFIG_X86_PC=y > # CONFIG_X86_VSMP is not set > # CONFIG_MK8 is not set > CONFIG_MPSC=y > # CONFIG_GENERIC_CPU is not set > CONFIG_X86_L1_CACHE_BYTES=128 > CONFIG_X86_L1_CACHE_SHIFT=7 > CONFIG_X86_INTERNODE_CACHE_BYTES=128 > CONFIG_X86_TSC=y > CONFIG_X86_GOOD_APIC=y > CONFIG_MICROCODE=y > CONFIG_MICROCODE_OLD_INTERFACE=y > # CONFIG_X86_MSR is not set > # CONFIG_X86_CPUID is not set > CONFIG_X86_HT=y > CONFIG_X86_IO_APIC=y > CONFIG_X86_LOCAL_APIC=y > CONFIG_MTRR=y > CONFIG_SMP=y > # CONFIG_SCHED_SMT is not set > CONFIG_SCHED_MC=y > CONFIG_PREEMPT_NONE=y > # CONFIG_PREEMPT_VOLUNTARY is not set > # CONFIG_PREEMPT is not set > CONFIG_PREEMPT_BKL=y > # CONFIG_NUMA is not set > CONFIG_ARCH_SPARSEMEM_ENABLE=y > CONFIG_ARCH_FLATMEM_ENABLE=y > CONFIG_SELECT_MEMORY_MODEL=y > CONFIG_FLATMEM_MANUAL=y > # CONFIG_DISCONTIGMEM_MANUAL is not set > # CONFIG_SPARSEMEM_MANUAL is not set > CONFIG_FLATMEM=y > CONFIG_FLAT_NODE_MEM_MAP=y > # CONFIG_SPARSEMEM_STATIC is not set > CONFIG_SPLIT_PTLOCK_CPUS=4 > CONFIG_RESOURCES_64BIT=y > CONFIG_NR_CPUS=8 > # CONFIG_HOTPLUG_CPU is not set > CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > CONFIG_IOMMU=y > # CONFIG_CALGARY_IOMMU is not set > CONFIG_SWIOTLB=y > CONFIG_X86_MCE=y > CONFIG_X86_MCE_INTEL=y > # CONFIG_X86_MCE_AMD is not set > # CONFIG_KEXEC is not set > # CONFIG_CRASH_DUMP is not set > CONFIG_PHYSICAL_START=0x20 > CONFIG_SECCOMP=y > # CONFIG_CC_STACKPROTECTOR is not set > # CONFIG_HZ_100 is not set > # CONFIG_HZ_250 is not set > CONFIG_HZ_1000=y > CONFIG_HZ=1000 > # CONFIG_REORDER is not set > CONFIG_K8_NB=y > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_ISA_DMA_API=y > CONFIG_GENERIC_PENDING_IRQ=y > > # > # Power management options > # > CONFIG_PM=y > CONFIG_PM_LEGACY=y > # CONFIG_PM_DEBUG is not set > # CONFIG_PM_SYSFS_DEPRECATED is not set > > # > # ACPI (Advanced Configuration and Power Interface) Support > # > CONFIG_ACPI=y > # CONFIG_ACPI_AC i
Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
I have a new Intel 965G board, and I'm trying to get DRI working. Direct rendering is enabled, but all GL programs crash immediately. The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the kernel says: [drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed Additionally, glxinfo says (in addition to its normal output): glxinfo: bufmgr_fake.c:1245: bmReleaseBuffers: Assertion `intel->locked' failed. This is with 2.6.19-rc2 (and -rc1). Here's a .config and dmesg: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19-rc2 # Fri Oct 13 13:42:19 2006 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set CONFIG_MPSC=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_NR_CPUS=8 # CONFIG_HOTPLUG_CPU is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 # CONFIG_REORDER is not set CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_PENDING_IRQ=y # # Power management options # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y # CONFIG_ACPI_HOTKEY is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CON