On Tue, Jan 10, 2012 at 08:44:20PM -0800, Keith Packard wrote: > On Tue, 10 Jan 2012 16:51:08 -0800, Eric Anholt <eric at anholt.net> wrote: > > > So they've gone out of their way to build broken stuff. Awesome. > > Well, in theory, the interrupt would be generated *before* the hardware > goes to RC6; when idle, I'm not exactly sure what the hardware would be > doing to generate interrupts. I agree, we still have no explanation for why the hw seems to forget to push out the irq/seqno write before going into sleep (and then seems to drop the irq right on the floor). I suspect that the windows driver just grabs frocewake every time it's interested in an interrupt and hence this irq/seqno signalling part without forcewake wasn't ever properly validated. After all there must be a reason for the multi-threaded forcewake stuff on windows - on Linux (before the voodoo patch at least) we don't use forcewake at all in any fastpath ... Unfortunately round-trip times with vpg are a disaster and we're not allowed to look at the windows kernel driver code to check ourselves :( I need to again work on getting some access to it. > > I'd say you've found the clue here -- I'm a lot happier with going with > > your patches now (and I was pretty happy with the gen7 side before). > > I'd just like to not mess with gen6 unless we've got missed irq bugs > > there to fix. > > Yeah, knowing that there might be interrupt funnies due to RC6 goes some > way to explaining why just avoiding RC6 helps. > > I wonder if any of this might explain the RC6 issues we see on SNB on > some hardware, and whether we should give this a try... I know, grasping > at straws, but still, it's about all we have at this point. I'm already playing around with patches that grab forcewake a bit more to work out a magic trick for semaphores vs. vt-d. Utter fail atm, everything I try seems to blow up faster :( So we still have an elephant somewhere. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
