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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061020164008.GA29810@tau.solarneutrino.net>
Date:	Fri, 20 Oct 2006 12:40:08 -0400
From:	Ryan Richter <ryan@....solarneutrino.net>
To:	Keith Whitwell <keith@...gstengraphics.com>
Cc:	Keith Packard <keithp@...thp.com>, dri-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: 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 {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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/