debugging an oops that kills the system

debugging an oops that kills the system

[Dan Upton]

Hi all,

I'm hoping for some pointers on debugging an oops that ultimately
hangs the system.  I'm doing some scheduler work and I can fairly
reliably duplicate the error on my machine, but the output is too
large for one screen and the system becomes unresponsive after the
crash so I can't scroll the console.  I tried purchasing a  USB->DB9
cable to log to a remote terminal, but so far I haven't had any luck
getting that to work.  Using kdump/kexec doesn't work either--I got
the second kernel to boot successfully using the magic sysrq example
in the documentation, but the second kernel doesn't boot with my
actual crash.  Any other suggestions for what I might do?

Thanks,
-dan

Re: debugging an oops that kills the system

[Roland Dreier]

 > I'm hoping for some pointers on debugging an oops that ultimately
 > hangs the system.  I'm doing some scheduler work and I can fairly
 > reliably duplicate the error on my machine, but the output is too
 > large for one screen and the system becomes unresponsive after the
 > crash so I can't scroll the console.  I tried purchasing a  USB->DB9
 > cable to log to a remote terminal, but so far I haven't had any luck
 > getting that to work.  Using kdump/kexec doesn't work either--I got
 > the second kernel to boot successfully using the magic sysrq example
 > in the documentation, but the second kernel doesn't boot with my
 > actual crash.  Any other suggestions for what I might do?

If you have two machines (it sounds like you do) and serial console is
not working for you (could be a setup problem -- do you have a
"console=" line on your kernel command line?), then netconsole might be
a good way to debug: Documentation/networking/netconsole.txt

 - R.

Re: debugging an oops that kills the system

[Dan Upton]

Thanks, I'd never come across that but it worked like a charm.  Now on
to the hard part, actually figuring out and fixing the bug ;)

-dan

On Tue, Oct 21, 2008 at 2:39 PM, Roland Dreier <rdreier@cisco.com> wrote:
>  > I'm hoping for some pointers on debugging an oops that ultimately
>  > hangs the system.  I'm doing some scheduler work and I can fairly
>  > reliably duplicate the error on my machine, but the output is too
>  > large for one screen and the system becomes unresponsive after the
>  > crash so I can't scroll the console.  I tried purchasing a  USB->DB9
>  > cable to log to a remote terminal, but so far I haven't had any luck
>  > getting that to work.  Using kdump/kexec doesn't work either--I got
>  > the second kernel to boot successfully using the magic sysrq example
>  > in the documentation, but the second kernel doesn't boot with my
>  > actual crash.  Any other suggestions for what I might do?
>
> If you have two machines (it sounds like you do) and serial console is
> not working for you (could be a setup problem -- do you have a
> "console=" line on your kernel command line?), then netconsole might be
> a good way to debug: Documentation/networking/netconsole.txt
>
>  - R.
>