[Intel-gfx] [PULL] drm-intel-next
jbarnes at virtuousgeek.org
Thu Jan 5 10:02:51 PST 2012
On Thu, 5 Jan 2012 16:24:08 +0100
Daniel Vetter <daniel at ffwll.ch> wrote:
> I'd also like to express my frustration with the general -next process for
> - This drm-intel-next tree is less than 24h ours old (if you look at when
> it showed up at an official place where both our QA and the community
> can pick it up and test it). I fear we'll ship yet another disaster like
> the stack eating bug the vt-d/ilk w/a patch caused with an unbounded
> recursion. Our QA actually caught it in testing, but there was simply
> not enough time to fix things up before the buggy code landed in -linus.
> - Because the drm-intel-next merge cycle started so late there has simply
> not been enough time to include quite a few bugfixes for serious issues
> like 20s delays in intial modeset, userspace-triggerable kernel OOPSes
> and deadlocks and reproducible hard hw hangs. For most of these there
> are testcases in intel-gpu-tools, and these issues span the entire set
> of hw generations drm/i915 currently supports. But this late it's imo
> no longer advisible to merge them, so we'll ship 3.3 with a bunch of
> known (and sometimes longstanding) serious issues that have fixes.
Yeah I have to second this and additionally complain about the patch
lossiness & latency. Part of this is my fault for not reviewing things
as much as I should, but those reviews often get lost too...
Eugeni's i2c patches are a good example. They've been out there since
early Oct, have received review and testing, and should have been in
-next for many months now (in previous releases!).
What can we do to improve the process to get trees updated more
regularly and get fixes integrated faster?
Jesse Barnes, Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Intel-gfx