Subject: How to debug kernel problems.
To: Steven E Lumos <firstname.lastname@example.org>
From: Ted Lemon <email@example.com>
Date: 04/24/1997 17:18:05
> It would be nice if anybody out there was willing to help people get
> started. We for example said that we more than happy to help debug
> the problem with hangs during disk access on 3100s, if somebody would
> just tell us what we needed to do, but apparently nobody thought it
> was worth the trouble. We'd also be willing to help with this, but
> since that kernel doesn't last more than 2 minutes without hanging on
> our 3100, there isn't much we can do.
It's generally harder to teach somebody to do something than to do it
yourself. So if you need to be taught how to debug a SCSI problem,
it'd be easier for Jonathan to just do it himself. The only way it's
worth his time to teach you is if you're then going to solve lots of
problems with the knowledge you gain from having him teach you.
The only way that you can help in a situation where you have a single
bug that you have to fix is if you climb the learning curve yourself.
Don't bug Jonathan unless you're *really* stuck. If you can't
articulate a clear question, you need to study the problem some more.
Often trying to articulate a clear question will actually reveal a
line of attack you hadn't thought of, so you won't actually have to
ask the question after all.
If you need to figure out where to start, look at the panic string and
grep through the sources until you find it, and then try to figure out
why it got printed and what sequence of events led up to it getting
printed. In the process of doing this, you'll begin to understand the
driver. Eventually, you may know enough to fix it. Along the way
you may come up with some good questions to ask.
That's what I do, anyway...