Date: 	Wed, 6 Sep 2000 12:52:29 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Availability of kdb
Newsgroups: fa.linux.kernel

On Wed, 6 Sep 2000, Tigran Aivazian wrote:
> 
> very nice monologue, thanks. It would be great to know Linus' opinion. I
> mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
> is a living being and not some set of rules written in stone so perhaps
> current stability/highquality of kdb suggests to Linus that it may be
> (just maybe) acceptable into official tree?

I don't like debuggers. Never have, probably never will. I use gdb all the
time, but I tend to use it not as a debugger, but as a disassembler on
steroids that you can program.

None of the arguments for a kernel debugger has touched me in the least.
And trust me, over the years I've heard quite a lot of them. In the end,
they tend to boil down to basically:

 - it would be so much easier to do development, and we'd be able to add
   new things faster.

And quite frankly, I don't care. I don't think kernel development should
be "easy". I do not condone single-stepping through code to find the bug.
I do not think that extra visibility into the system is necessarily a good
thing.

Apparently, if you follow the arguments, not having a kernel debugger
leads to various maladies:
 - you crash when something goes wrong, and you fsck and it takes forever
   and you get frustrated.
 - people have given up on Linux kernel programming because it's too hard
   and too time-consuming
 - it takes longer to create new features.

And nobody has explained to me why these are _bad_ things.

To me, it's not a bug, it's a feature. Not only is it documented, but it's
_good_, so it obviously cannot be a bug.

"Takes longer to create new features" - this one in particular is not a
very strong argument for having a debugger. It's not as if lack of
features or new code would be a problem for Linux, or, in fact, for the
software industry as a whole. Quite the reverse. My biggest job is to say
"no" to new features, not trying to find them.

Oh. And sure, when things crash and you fsck and you didn't even get a
clue about what went wrong, you get frustrated. Tough. There are two kinds
of reactions to that: you start being careful, or you start whining about
a kernel debugger.

Quite frankly, I'd rather weed out the people who don't start being
careful early rather than late. That sounds callous, and by God, it _is_
callous. But it's not the kind of "if you can't stand the heat, get out
the the kitchen" kind of remark that some people take it for. No, it's
something much more deeper: I'd rather not work with people who aren't
careful. It's darwinism in software development.

It's a cold, callous argument that says that there are two kinds of
people, and I'd rather not work with the second kind. Live with it.

I'm a bastard. I have absolutely no clue why people can ever think
otherwise. Yet they do. People think I'm a nice guy, and the fact is that
I'm a scheming, conniving bastard who doesn't care for any hurt feelings
or lost hours of work if it just results in what I consider to be a better
system.

And I'm not just saying that. I'm really not a very nice person. I can say
"I don't care" with a straight face, and really mean it.

I happen to believe that not having a kernel debugger forces people to
think about their problem on a different level than with a debugger. I
think that without a debugger, you don't get into that mindset where you
know how it behaves, and then you fix it from there. Without a debugger,
you tend to think about problems another way. You want to understand
things on a different _level_.

It's partly "source vs binary", but it's more than that. It's not that you
have to look at the sources (of course you have to - and any good debugger
will make that _easy_). It's that you have to look at the level _above_
sources. At the meaning of things. Without a debugger, you basically have
to go the next step: understand what the program does. Not just that
particular line.

And quite frankly, for most of the real problems (as opposed to the stupid
bugs - of which there are many, as the latest crap with "truncate()" has
shown us) a debugger doesn't much help. And the real problems are what I
worry about. The rest is just details. It will get fixed eventually. 

I do realize that others disagree. And I'm not your Mom. You can use a
kernel debugger if you want to, and I won't give you the cold shoulder
because you have "sullied" yourself. But I'm not going to help you use
one, and I wuld frankly prefer people not to use kernel debuggers that
much. So I don't make it part of the standard distribution, and if the
existing debuggers aren't very well known I won't shed a tear over it.

Because I'm a bastard, and proud of it!

			Linus

From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Availability of kdb
Date: 	6 Sep 2000 14:03:06 -0700
Newsgroups: fa.linux.kernel

In article <39B6A683.3F75DC9D@timpanogas.com>,
Jeff V. Merkey <jmerkey@timpanogas.com> wrote:
>Linus Torvalds wrote:
>
>> Apparently, if you follow the arguments, not having a kernel debugger
>> leads to various maladies:
>>  - you crash when something goes wrong, and you fsck and it takes forever
>>    and you get frustrated.
>>  - people have given up on Linux kernel programming because it's too hard
>>    and too time-consuming
>>  - it takes longer to create new features.
>> 
>> And nobody has explained to me why these are _bad_ things.
>
>They are bad because they cost people money that could be spent more
>productively in other areas due to the lengthening of the development
>process and the support costs.

Ehh..

Explain to me again why I should care?

Read my posting again.  Read the "I'm a bastard" part twice.  Realize
that in the end, I don't care who speds money, time, and effort.  In the
end, I think that we're better off _without_ code that hasn't been
thought through. 

More code, more people, more money.  Why should I think they are good
things?

The people, the projects, the companies that come though that test of
fire victorious are not only stronger for it, but more importantly, they
are the kind of people, projects and companies who DID get through.
Dedicated. Smart. And careful.

Think of rabbits. And think of how the wolf helps them in the end. Not
by being nice, no. But the rabbits breed, and they are better for having
to worry a bit.

		Linus

Date: 	Wed, 6 Sep 2000 14:33:36 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Availability of kdb
Newsgroups: fa.linux.kernel

On Wed, 6 Sep 2000, Daniel Phillips wrote:

> Linus Torvalds wrote:
> >
> > And quite frankly, for most of the real problems (as opposed to the stupid
> > bugs - of which there are many, as the latest crap with "truncate()" has
> > shown us) a debugger doesn't much help. And the real problems are what I
> > worry about. The rest is just details. It will get fixed eventually.
> 
> Yes, no doubt you agree that stepping through the code with a source
> level debugger even once would have caught this one:

No I definitely do not agree.

In fact, I would never have seen that problem with _any_ debugger. It
simply would not have happened for me.

And guess what? I saw the bug without any debugger within minutes of
having been told what the problem was. A debugger would not have helped.

And that is the case in 99% of all cases. In most cases the people who see
the problem aren't the same people who can debug them. Giving such a
person a debugger doesn't help.

		Linus

Date: 	Wed, 6 Sep 2000 14:36:48 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Availability of kdb
Newsgroups: fa.linux.kernel

On Wed, 6 Sep 2000, Dan Hollis wrote:

> On Wed, 6 Sep 2000, Alan Cox wrote:
> > For things like driver debugging its the only way to work. Hardware simply does
> > not work like the manual says and no amount of Zen contemplation will ever 
> > make you at one with a 3c905B ethernet card. 
> 
> This is probably the best argument for a kernel debugger.
> 
> Adding debug code (printk, if/then/BUG() etc) to track down a driver bug
> sometimes changes behaviour enough to turn it into a heisenbug. In these
> cases a kernel debugger is the best way to swat it.

Ehh? And exactly _how_ would a debugger help it.

Especially as Alan quoted an example of a driver bug that didn't get fixed
for several months because the maintainer didn't have the hardware.

What would a debugger have done? 

Are you _seriously_ expecting that non-programmers start using kernel
debuggers to send in good bug-reports? Grow up, get a clue, and smell the
roses. Not going to happen. Especially as a kernel debugger tends to
require a second machine, and even then you only get to break
automatically on events that would have caused a kernel oops anyway.

Otherwise you need to know a hell of a lot more, like setting breakpoints
etc.

Testing is important for device drivers. Debuggers are not.

			Linus

Date: 	Wed, 6 Sep 2000 14:41:58 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Availability of kdb
Newsgroups: fa.linux.kernel

On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
> > 
> > Think of rabbits. And think of how the wolf helps them in the end. Not
> > by being nice, no. But the rabbits breed, and they are better for having
> > to worry a bit.
> 
> You know those huge, sharp teeth on the wolf?  Want to make them longer
> and sharper?  Put in a kernel debugger, Linus, and the wolf will be even
> more ferocious.  I appreciate the honest, open response, BTW.  

No, no.

The debugger is akin to giving the _rabbits_ a bazooka. The poor wolf
doesn't get any sharper teeth.

Yeah, it sure helps against wolves. They explode in pretty patterns of
read drops flying _everywhere_. Cool.

But it doesn't help against a rabbit gene pool that is slowly
deteriorating because there is nothing to keep them from breeding, and no
darwin to make sure that it's the fastest and strongest that breeds.

You mentioned how NT has the nicest debugger out there. 

Contemplate it.

		Linus

Date: 	Wed, 6 Sep 2000 15:15:17 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Availability of kdb
Newsgroups: fa.linux.kernel

On Wed, 6 Sep 2000, Alan Cox wrote:
> > 
> > What would a debugger have done? 
> 
> Let the end user give me essential answers on what was happening at the failure
> point. Think of it as a crash dump tool with extra controls

Sure. I just don't see many end-users single-stepping through interrupt
handlers etc.

But yes, there probably are a few. 

But problems that tend to be hard to debug are things that don't happen
all the time. Or require special timing to happen. And I don't think
you'll find that those are very easy to attach to with a debugger either.
So the guy at the debugger end has to be really good.

Basically, I'd hate to depend on that.

> When was the last time you wrote a device driver for some warped piece of PCI
> technology that didn't work like the book says and for which you can neither
> get more info or pop over to the next cubicle and ask the hardware designer ?

That would be the CardBus controller. Yeah, still fighting that one, but
we solved another bug today. Richard Gooch would have been able to use a
debugger for that one, but I don't know what he could have done with one
in that case.

		Linus

Date: 	Tue, 12 Sep 2000 08:04:58 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: Availability of kdb
Newsgroups: fa.linux.kernel

On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
> Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> of software that can quickly get out of sync if it's maintained
> separately from the tree -- the speed at which changes occur in Linux
> would render it a very difficult project to maintain.  If there's going
> to be one (whichever one it is) it would need to be maintained and
> dragged along with the kernel proper or it would be a maintenance
> nightmare.  Linus' dislike of the kernel debugger concept would also

If the kernel debugger is done right, it won't require massive changes
as Linux continues to change.  Does gdb need to be modified based on the
programs that it debugs?  

I can certainly see that certain kernel debugger modules (say, those
that muck with spinlocks for deadlock debugging) might require updating
as the kernel changes, but the overall design goal for any good kernel
debugger is to minimize the number places where it has to hook into the
real parts of the kernel.  For one thing, this reduces the chance of
"heisenbugs" which disappear once you enable the kernel debugger, since
if adding the kernel debugger modifies the code paths, the bug is much
more likely to go away.  For another, if you want to have the kernel
debugger enabled by default, having lots of hooks into the main parts
kernel makes it much more likely that the whole thing will be a massive
speed/performance hit.

If keeping the kernel debugger outside of the kernel is inspires people
to minimize the number of hooks and patches that are needed to main
parts of the kernel, then that's probably one of the best reasons to
keep it ouside of the mainline kernel distribution.

					- Ted

Date: 	Sun, 17 Sep 2000 20:40:33 -0700
From: Larry McVoy <lm@bitmover.com>
Subject: Re: Availability of kdb
Newsgroups: fa.linux.kernel

On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> Um, for what ever it is worth, if you want to compare "power user" carpentry
> to "hand tools only" you can actually do it fairly easily on PBS in the US.
> There used to be a program done by a guy who did everything by hand.  I
> loved to watch it, especially the parts where he cut himself badly because
> there are somethings it is dumb to do with hand tools, but he was stuck with
> his dumb rule.  There's another show, still on, called "The New Yankee
> Workshop". I love to watch it, just to count the number of power tools Norm
> Abrams manages to use in a single project.  (I think the most I saw in one
> one hour episode was 40-something.)
> 
> Craftsmanship does *not* come from artificial rules about what tools you are
> allowed to use.  There were hack carpenters when there weren't any power
> tools, and the cabinet makers I know who do the best work (the sort that
> gets them several thousand dollars a piece for small pieces of furniture)
> use every power tool they find appropriate to their work; just as they
> construct and use jigs and rely on all the other "tricks of the trade".
> 
> Craftsmanship is in the way you approach what you do, not in the tools you
> use to do it.  And, frankly, if you wish to artificially limit your use of
> tools, all you are doing is hobbling yourself.

Ahh, now we're having fun.  It just so happens that I can speak to all
of these topics; not only have I seen the shows mentioned, but I have
a shop out the back which has both a pile of power tools and a pile of
antique tools (oldest one that I know of was made around 1837, a great
big spokeshave).  I use all of them regularly, no collector-foo here,
thank you.  I tend to retreat to working with hand tools when all this
geek stuff gets to be a bit much.

Cabinet making craftsmanship absolutely comes from a firm knowledge of
hand tools.  I'll bet you anything you want that the guy who sells that
$3K furniture knows exactly what a Norris is and has used one.  Probably
still does (OK, mebbe it's a Lie-Nielsen these days).

I've also used a number of kernel debuggers - kadb back at Sun, a monitor
back at ETA (amazingly similar in spirit to RT/Linux), SGI's monstrosity,
and probably others.

That said, who gives a hoot what I have or what I have used?  The question
is: does Linus have a point or not?  And the answer is, you bet he does.

Linus is saying that if you need a debugger then you don't know the code.
And if you don't know the code, then you shouldn't be hacking the code.
A debugger does little besides cover up a lack of knowledge.

It's not an easy to take point of view because by definition, most
people don't really know the code so most people want a debugger.
Linus would just as soon that you learn the code well enough that a
debugger becomes pointless.

I'm sort of in the middle.  I know BitKeeper very well, and it's actually
a larger wad of code than the kernel if you toss out the device drivers.
About the only thing I ever want a debugger for is a stacktrace back.  If
you give me that, I usually don't need anything else; and in general, you
shouldn't either.  You should *know* why you got to a particular place,
if you don't know that then how can you fix the bug?

So I'm gonna side with Linus on this one, if you make it hard now, it will
be easier later.  It also increases the quality of the people submitting
patches, which is a good thing.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

From: viro@weyl.math.psu.edu (Alexander Viro)
Newsgroups: comp.os.linux.development.system
Subject: Re: LINUX Device Driver Developer Needed
Date: 12 Jul 2002 21:28:49 -0400
Message-ID: <agnvoh$d0r@weyl.math.psu.edu>

In article <8768a1ed.0207121650.704ea8ac@posting.google.com>,
ChessForFun <chessforfun@hotmail.com> wrote:

>How do you actually debug your code? With printk's?

99% - with head.  Which includes writing the code in the way that's
easy to understand and debug.  The rest - several printks and then
use of head...

Most of the trouble with debugging comes from the code you don't
really understand - which is avoidable if you spend some time
on making it clean when you write it.  And on cleaning it up again
and again...

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34
Original-Message-ID: <Pine.LNX.4.44.0209151103170.10830-100000@home.transmeta.com>
Date: Sun, 15 Sep 2002 18:06:47 GMT
Message-ID: <fa.l0t1o9v.1k1u01r@ifi.uio.no>

On Sun, 15 Sep 2002, Daniel Phillips wrote:
>
> Let's try a different show of hands: How many users would be happier if
> they knew that kernel developers are using modern techniques to improve
> the quality of the kernel?

You're all talk and no action.

The last time I looked, the people who really _do_ improve the quality of
the kernel don't tend to care too much about debuggers, or are at least
capable to add a patch on their own.

In fact, of the people who opened their mouth about the BUG() issue, how
many actually ended up personally _debugging_ the BUG() that we were
talking about?

I did. Matt probably did. But I didn't see you fixing it with your
debugger.

So next time you bring up the kernel debugger issue, show some code and
real improvement first. Until then, don't spout off.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [git pull] kgdb-light -v10
Date: Tue, 12 Feb 2008 16:26:46 UTC
Message-ID: <fa.a7i5jPvSHKaPXjGucy2+vxlUFpY@ifi.uio.no>

On Tue, 12 Feb 2008, Andi Kleen wrote:
> >
> > KGDB does a very straightforward "all CPUs enter controlled state"
> > transition when the session begins, and at the end an "all CPUs
> > continue" transition.
>
> Yes and the session has no fixed time limit.

Quite frankly, if kgdb starts doing something "fancy", there is no way
I'll merge it.

This includes things like having "breakpoint reservations" (discussed
earlier) and just generally trying to add lots of infrastructure to make
kgdb "fit in" to the kernel.

The fact is, not having kgdb enabled should have _zero_ impact on the
kernel, but the implication is also that when you *do* enable kgdb, that
shouldn't change anything visible either: the rest of the kernel should
simply not _possibly_ be able to even tell or care (which is why
breakpoint reservations are out - they are against the whole point of
debugging a unmodified kernel).

So kgdb in my opinion will *have* to step on some other kernel
infrastructure. I also think that things like timeouts are not something
the client should do - if a kgdb lock never gets through, then it should
be the debugging end that should just react to ^C and tough titties: it's
not like there's a whole lot to be done.

In other words: I think the kgdb patches have become a lot more palatable
over the last week, but I think so exactly because they have gotten
smaller and less invasive. Anything that evokes any discussion AT ALL
should just be removed. It really should be that simple.

[ The exception being that I think hw breakpoint support should be added
  back in - never mind that it won't work if the "native kernel" also uses
  them. Tough.

  If the debugger screws up the hw breakpoint state, that's a debugger
  error. I'd hope that the remote debugger *defaults* to just re-writing
  the instruction stream for that reason, but if you want to do a data
  breakpoint, you simply *have* to use the hw breakpoints for kgdb.

  And you just need to live with the fact that it simply won't be possible
  to do if the client wants to use hw breakpoints too. If the client
  starts using hw breakpoints - tough titties, it takes them. ]

So keep the damn thing really simple, and don't try to handle every
possible thing. We expect the debugger side to have a person with some
flexibility on it.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [git pull] kgdb-light -v10
Date: Tue, 12 Feb 2008 16:48:56 UTC
Message-ID: <fa.Zt3UlWtDxI1tYPLBpH5erwrEsmY@ifi.uio.no>

On Tue, 12 Feb 2008, Ingo Molnar wrote:
>
> * Andi Kleen <andi@firstfloor.org> wrote:
> >
> > Stopping all CPUs for indefinite time very much seems like "breaking a
> > correctly working system" to me. [...]
>
> well, this is a small detail, but still you are wrong, and on a
> correctly working system this will not occur. (if yes, tell me how)

Quite frankly, I don't see why the kernel kgdb layer should have *any*
code like this at all.

The one who is actually debugging is the one who should decide which CPU's
get stopped, and which don't.

I realize that the gdb remote protocol is probably a piece of crap and
cannot handle that, but hey, that's not my problem, and more importantly,
I don't think it's even a *remotely* valid reason for making bad decisions
in the kernel. gdb was still open source last time I saw, and I think it's
reasonable to just say:

 - the kgdb commands should always act on the *current* CPU only
 - add one command that says "switch over to CPU #n" which just releases
   the current CPU and sends an IPI to that CPU #n (no timeouts, no
   synchronous waiting, no nothing - it's like a "continue", but with a
   "try to get the other CPU to stop"

Yes, other CPU's will obviously often end up stopping due to waiting for
some spinlock or other if we stop one, but that's a separate issue, and
quite often it might be sufficient - and what we want.

And yes, you'd likely have to add some support to gdb to make this
_usable_, but now all that usability crap, all those timeouts for "stop
all CPU's" are now in user space on the _debugger_ side. That can be as
fancy as it wants to be.

And maybe this isn't realistic. I'm not saying "we _must_ do it this way",
I just want to say that the kernel kgdb layer should be as thin as
humanly possible, and maybe the right thing to do is to simply totally
punt on the whole "stop other cpu's" issue and make it a debugger-side
question.

In other words, is it perhaps possible to just *get*rid*of* that
"kgdb_active" and "nmicallback" and the whole multi-CPU roundup? Just use
a kgdb spinlock around the stuff that actually sends and receives
individual packets, and expect the debugger side to sort them out (yeah, I
suspect this involves having to add the CPU ID to each packet).

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [git pull] kgdb-light -v10
Date: Tue, 12 Feb 2008 18:13:55 UTC
Message-ID: <fa.AvCjKo66TkPJZWtI43yryozaRhs@ifi.uio.no>

On Tue, 12 Feb 2008, Andi Kleen wrote:
>
> >  - the kgdb commands should always act on the *current* CPU only
> >  - add one command that says "switch over to CPU #n" which just releases
> >    the current CPU and sends an IPI to that CPU #n (no timeouts, no
> >    synchronous waiting, no nothing - it's like a "continue", but with a
> >    "try to get the other CPU to stop"
>
> The problem I see here is that the kernel tends to get badly confused
> if one CPU just stops responding. At some point someone does an global
> IPI and that then hangs.  You would need to hotunplug the CPU which
> is theoretically possible, but quite intrusive.

You're thinking about this totally *wrong*.

You definitely do not want to hot-unplug or isolate anything at all.
That's explicitly against the whole point of kgdb not changing what it is
trying to measure.

Just let the other CPU's hang naturally if they need to wait for IPI's
etc. What's the downside? That's what you were trying to do in the first
place by having the kgdb callback!

So you can't have it both ways. Either serializing other cpu's with kgdb
is good (the whole "kgdb_nmicallback" thing or whatever it was called), in
which case it's also perfectly ok to just let them stop when waiting for
IPI's.

My point was *not* that kgdb should take control of one CPU, and the other
CPU's should continue to work as if nothing happened. That is insane and
impossible (since you may be stopping a CPU while it holds central
spinlocks etc). No, my point was that I think kgdb should be as light and
non-intrusive as possible, and that any "higher level behaviour" (like the
decision of whether to try to synchronize other CPU's or not) should be
left to the debugger.

But only if that makes kgdb patches less intrusive!

In other words, I'm not at all trying to push any particular solution
here, except for the "keep it simple, and anything even remotely debatable
or intrusive to the system should be excised". And I wanted to point out
that maybe all these timeout etc decisions can be pushed to the debugger.

So I think we can either:

 - have no timeouts or other fancy crap _at_all_, with very simple locking
   (ie looks what v10 mostly seems to do)

 - or you do the fancy dance entirely in the remote debugger.

I don't care. The only thing I care about is that kgdb support never
_ever_ shows up in any interesting code, and that it remains totally
invisible to essentially all of the kernel except the place that would
otherwise print out an oops.

And I absolutely don't want it to be fancy, I want it to be so simple that
even _I_ can look at it and say "I think this is crap, but it's _trivial_
crap".

IOW: as long as people keep arguing about it, I sure as hell won't ever
merge it. It needs to be so _obvious_ and so _minimal_ that I can feel
that I finally don't need to care.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [git pull] kgdb-light -v10
Date: Tue, 12 Feb 2008 19:03:39 UTC
Message-ID: <fa.MmdPS1cqvmf2m6vjlCBlJfkaEAk@ifi.uio.no>

On Tue, 12 Feb 2008, Andi Kleen wrote:
>
> There tend to be timeouts (e.g. softlock/nmi watchdog at least). I think
> some of the IPIs eventually time out too.  In general losing a lot
> of time can lead to weird side effects.

I do agree that kgdb and watchdogs aren't like to work well together. And
I don't think you can sanely expect to not have a "disable lockup
detection" when you start poking around with kgdb.

We also just have to expect that time will also stop while sometbody is
messing around with kgdb.

So I don't dispute that any kernel debugger will *always* be intrusive in
those ways. That's pretty inevitable. I just think the code itself can try
to avoid hooking into various places all over the map.

			Linus