broadwell instability and mandatory igt for gem/mm/gtt changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey all,

It has come to my attention that there is a pretty serious bug in i915
on Broadwell for 4.10 and 4.11 released kernels, this means it has
probably been in the intel-next tree for at least 4 if not 6 months,
and gone unnoticed. How does something like this get into Linus tree,
and remain in the Linus tree for two releases?

Back when we started doing continuous merging into drm-intel-next, I
realised this was going to be a problem, and was told it wouldn't as
review and CI would catch things. The problem as I see it, is the dump
and run mentality has taken hold inside Intel, and there is a lack of
ownership of bugs or areas of the kernel. There seems to be a lack of
caring by internal engineers about anything not in their direct line
of sight. This needs to change, engineers contributing to i915 need to
start owning and fixing their code, not just dumping and moving on.
The problem I have with the long tail of commits going into Linus tree
is that reverting is really difficult 3-4 weeks later since usually
things have been built on top of the pile of crap that is causing the
problems,

However since this probably won't happen, we need to start relying on
CI probably to trap things, I'm asking Daniel and other committers to
drm-intel-next to start enforcing that complete intel-gpu-tools tests
are available before any commits that affect things at lowlevel across
the board (i.e. gem, gtt programming, shrinker), and also for any new
UABI for features that are using things like 48-bit addressing etc. I
don't want any code being merged to drm-intel-next unless the
developer has done a complete intel-gpu-tools regression run on at
least two major platforms themselves, without relying on CI.

Please forward this email to any Intel management/engineering that are
off this list, but having a complete platform 2 generations old broken
for 6 months isn't acceptable and someone needs to own that, and
ensure stable gets patches ASAP.

Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux