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]
