LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* debugging an oops that kills the system
@ 2008-10-21 17:14 Dan Upton
  2008-10-21 18:39 ` Roland Dreier
  0 siblings, 1 reply; 3+ messages in thread
From: Dan Upton @ 2008-10-21 17:14 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: debugging an oops that kills the system
  2008-10-21 17:14 debugging an oops that kills the system Dan Upton
@ 2008-10-21 18:39 ` Roland Dreier
  2008-10-21 19:44   ` Dan Upton
  0 siblings, 1 reply; 3+ messages in thread
From: Roland Dreier @ 2008-10-21 18:39 UTC (permalink / raw)
  To: Dan Upton; +Cc: linux-kernel

 > 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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: debugging an oops that kills the system
  2008-10-21 18:39 ` Roland Dreier
@ 2008-10-21 19:44   ` Dan Upton
  0 siblings, 0 replies; 3+ messages in thread
From: Dan Upton @ 2008-10-21 19:44 UTC (permalink / raw)
  To: Roland Dreier; +Cc: linux-kernel

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.
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-10-21 19:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-21 17:14 debugging an oops that kills the system Dan Upton
2008-10-21 18:39 ` Roland Dreier
2008-10-21 19:44   ` Dan Upton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).