Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 {0x02000003, 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux