* David Miller <[email protected]> wrote:
> From: Ingo Molnar <[email protected]>
> Date: Tue, 17 Jul 2007 00:37:18 +0200
>
> > I think if you leaned back and thought it through, and if you
> > applied this scenario to a bad scheduler commit from me that broke
> > your box, you'd readily agree with me =B-) (which scenario is purely
> > hypothetical, my scheduler commits are all 100% perfect of course
> > ;-)
>
> Actually I'd probably send you a patch for any bug I found that
> triggered on sparc64, since that's faster than asking you to fix a bug
> that you are unlikely to be able to trigger on your own systems.
>
> But that's just how I operate.
>
> Ask Thomas Gleixner. Every single hrtimers/nohz bug I've found on
> sparc64, I sent him either a full fix or a full analysis of the bug
> and a description of exactly what is going on and what needs to be
> changed so he can compose the bug fix patch with minimal effort.
yeah, i too usually try to fix bugs straight away - just check:
git-log net drivers/net | grep "Author: Ingo Molnar"
but in this current case i was freshly back from a few days off, had
quite a backlog after a rather complex set of merges and i just didnt
have the time.
And i really applaud you for the clockevents/dynticks contributions (i
loved your dynticks patches and the clockevents framework fixes that
resulted out of it), but i really, really think this case is apples to
oranges. I had some urgent hacking to do in some completely different
area (not networking) and i ran across that networking regression and
spent more than an hour on bisecting it.
The bad commit looked simple so i thought the person who is doing it
(Olaf) would immediately see the bug (i certainly didnt see it). It's
also not that easy to debug that box, the only remote debugging
interface to it is ... netconsole. If i were into networking changes
right now i'd probably have tried to debug and fix it straight away.
So instead i opted to bisect it, to give you the exact bad commit, give
you full logs of the incident and an offer to run arbitrary patches
immediately.
There's also little loss from the revert AFAICS: the commit went into
your tree on July 11th and went upstream July 12th and i found it on
July 16th. So (unless the commit dates are deceiving me) it does not
seem to be an over-tested patch with lots of QA value (yet), and it's
not some critical commit that another 100 commits grew to depend on.
It's nevertheless a fix we want to have, and i'm willing to test
anything.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
