Jason Wessel wrote:
quoted text
> The only place I could foresee that kgdb could be eating extra cycles i=
n=20
quoted text
> the runtime case is from the die_notifier processing.  Any kind of=20
> exception such as a page fault, trap etc... will have a few extra ops=20
> and checks of variables so as to determine if the debugger should take =

quoted text
> the exception.  It looks to me like it would even benefit to add the=20
> check at the top of the notify hook for kgdb to exit immediately if the=
=20
quoted text
> debugger is not attached.
>=20
> I have contemplated making some changes to KGDB so as to make the=20
> registration to the die_notifier to be dynamic with attaching and=20
> detaching of the debugger.  If this is done, I would also make a change=
=20
quoted text
> to allow for the case where the kernel would wait for the debugger to=20
> attach on any fatal fault.

At this chance... Reminds me that this old issue still seems to be
unsolved in current kgdb:

http://www.mail-archive.com/kgdb-bugreport@lists.sourceforge.net/msg00442=
=2Ehtml

I'm only looking at that spot in kgdb right now and /may/ oversee new
border conditions elsewhere. But my feeling is there are none.

Jan (looking forward to see kgdb merged)