On 8/12/06, Chris Jones <jonesc@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx 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
