Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34

[Daniel Phillips <phillips@arcor.de>]

On Sunday 15 September 2002 21:43, Andrew Morton wrote:
> I suspect the example which you give is not a very typical one.  Generally
> people use kgdb for poking around looking at kernel state.  I almost never
> single-step.  I set breakpoints so that I can inspect state within a
> particular context, and for coverage testing ("is this path being executed").

Right, I almost never single-step either.  Probably, my favorite technique
is to replace BUG() with asm("int3").

> Also as a replacement for printk/rebuild/reboot.

Yup.  I still use a lot of printks, but they are mostly for tracing, not
triangulation.

> Also for inspecting ad-hoc instrumentation: just add `some_global_int++;'
> and then take a look at its value - much quicker than exposing it via /proc.

Yep, I noticed you doing that, very useful, I picked up that technique
from you.  Then I made a little all-purpose proc interface for myself
to make it easy to export my stats structures, which is kind of nice too,
because then you can put a patch out with the hooks still in it, making
it easier for others to participate in the analysis.

> It's also very good to have kgdb on hand when you happen to hit a
> really rare bug - I hit a weirdo request queue corruption thing the
> other day, an hour into a `dbench 1024' run.  Was able to get a
> decent amount of information.  Heaven knows how long it would take
> to make that bug trigger a second time...

Yes, this last one applies equally to kdb, but since I'm not relying
on kdb at the moment, best to leave the lid on that can of flamable
material.

-- 
Daniel