options to debug kernel hangs ?

[Tod Merley]

On 8/12/06, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> Hi,
>
> I want to try and debug why the 2.6.17 kernels hang on on my system when
> rebooting from a suspend-to-disk. 2.6.16 ones seems fine. Unfortunately the
> hang happens early, just after the "resuming from /dev/hda9" message, so I
> don't get much in the way of info. I have to hard reset.
>
> Can anyone suggest anything I can do to help debug this.
>
> Are there any kernel options I could use to get more information out the the
> kernel as it loads ?
>
> Would it help if I rebuilt the kernel myself, turning on or off any options ?
>
> Are there anything I can do when the system is hung - I've tried all the
> control sequences I know  to get it to tell me something.
>
> ANY suggestions gratefully received - I would really like to try and get to
> the bottom of this.
>
> cheers Chris
>
> --
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>

Hi Chris!

I am not an expert but others have not come forward for you yet (they
would be most welcome to).

If it were me I would:

1. Google my hardware (computer (probably laptop I suppose) brand and
model number) along with the Linux used and perhaps the kernel number
and the description of the problem in some detail.  This is a process
and you are encouraged to make several searches as you go changing the
names and being less specific about model and all.

--------- the following is from another problem but most all directly
applies ------

2. Upon a "hang" I would boot into Puppy Linux (or Knoppix, or Ubuntu
Live, or any rescue disk), mount the Linux partition and look in
/var/log.  Probably while there you might do a "tail" command on:

debug and/or debug.0
dmesg
kern.log and/or kern.log.0
lastlog
messages and/or messages.0
syslog and/or syslog.0
udev
user.log and/or user.log.0
Xorg.0.log and possibley Xorg.0.log.old

My tendency here is to do a "cp /var/log/dmesg
/home/mydirectory/Desktop/dmesg.frz" to take a "snapshot" of the file.
  I would also do this for kern.log, messages, udev and Xorg.0.log.
Then you can do a "tail dmesg.frz" when you reboot and see what is
there (also "less dmesg.frz").  These logs may contain a hint as to
what happened.  It is probably not a bad idea to migrate to /var/log
first thing after the re-boot and check the files above using the
"tail" command.

2a. While booted into the Puppy, Knoppix, or other different
distribution option capture it's /etc/X11/xorg.conf file (and perhaps
it's /var/log Xorg.0.log file).

3. Using the "memtest" boot option in Live Ubuntu, or Knoppix, or
Puppy (hit any key during the countdown or select it from your boot
options) run a memtest for a
couple of hours.  Sometimes.

4.  Look for evidence of tampering (virus etc..). Do a virus scan and all.

--------------------- from the past ended  -------------------

5. Before you re-boot from a hang try doing a ctl+alt+F1 and see if
you land in a terminal screen.  If you do you can snoop around as
mentioned above without the re-boot having been done.  Also if you did
land in a terminal try a ctl+alt+F7.  Some of the messages there can
be useful.

I often see "suspend to disk" related problems here so I will now go
to Google and start with "how does suspend to disk work in Fedora Core
5".  I may well have more to contribute later.

Good Hunting!

Tod