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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
