On Thu, Dec 11, 2014 at 6:54 AM, Dave Jones <da...@redhat.com> wrote:
>
> So either one of those 'good's actually wasn't, or I'm just cursed.
Even if there was a good that wasn't, that last "bad" (6f929b4e5a02)
is already sufficient just on its own to say that likely v3.16 already
had the problem.
Just do
gitk v3.16..6f929b4e5a02
and cry.
(or "git diff --stat -M v3.16...6f929b4e5a02" to see what that commit
brought in from the common ancestor).
So I'd call that bisect a failure, and your "v3.16 is fine" is
actually suspect after all. Which *might* mean that it's some hardware
issue after all. Or there are multiple different problems, and while
v3.16 was fine, the problem was introduced earlier (in the common
ancestor of that staging tree), then fixed for 3.16, and then
re-introduced later again.
Anyway, you might as well stop bisecting. Regardless of where it lands
in the remaining pile, it's not going to give us any useful
information, methinks.
I'm stumped.
Maybe it's worth it to concentrate on just testing current kernels,
and instead try to limit the triggering some other way. In particular,
you had a trinity run that was *only* testing lsetxattr(). Is that
really *all* that was going on? Obviously trinity will be using
timers, fork, and other things? Can you recreate that lsetxattr thing,
and just try to get as many problem reports as possible from one
particular kernel (say, 3.18, since that should be a reasonable modern
base with hopefully not a lot of other random issues)?
Together with perhaps config checks. You've done some those already.
Did it reproduce without preemption, for example?
Does anybody have any smart ideas?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
