Help Debugging a Freeze

[SiriusStarr]

Hi all,

I need assistance debugging a particularly pernicious issue I've been having. I'm running Fedora 17, but the problem has been occurring since 16.

My system will occasionally freeze. The mouse remains responsive, but Gnome/all applications are frozen, can't click on anything, etc. This seems to be in some way related to memory use, since it only occurs if I'm over about 2.3 GB used (out of 3.3 GB used total) and will typically occur quite rapidly once I cross that boundary. It does not seem to be associated with any particular program I have open that I have been able to find, though it's possible it's due to Firefox or gnome-shell or something that is ubiquitously running. I can switch virtual consoles freely when it occurs, and the system works fine if I log in to one of the consoles, but the graphical one remains frozen. This issue has frequently caused me to lose work, since it will lock up completely without any way to save what I'm doing.

Because this is such a seemingly global issue, I have no idea where to begin as far as trying to debug the issue. Google has not yielded anything useful, and at this point I have no idea if it's Gnome or my graphics drivers or X11 or what. Suggestions for log files to look at, etc.?

Thanks,
Sirius

[cvrpacp]

Originally Posted by SiriusStarr

Hi all,

I need assistance debugging a particularly pernicious issue I've been having. I'm running Fedora 17, but the problem has been occurring since 16.

My system will occasionally freeze. The mouse remains responsive, but Gnome/all applications are frozen, can't click on anything, etc. This seems to be in some way related to memory use, since it only occurs if I'm over about 2.3 GB used (out of 3.3 GB used total) and will typically occur quite rapidly once I cross that boundary. It does not seem to be associated with any particular program I have open that I have been able to find, though it's possible it's due to Firefox or gnome-shell or something that is ubiquitously running. I can switch virtual consoles freely when it occurs, and the system works fine if I log in to one of the consoles, but the graphical one remains frozen. This issue has frequently caused me to lose work, since it will lock up completely without any way to save what I'm doing.

Because this is such a seemingly global issue, I have no idea where to begin as far as trying to debug the issue. Google has not yielded anything useful, and at this point I have no idea if it's Gnome or my graphics drivers or X11 or what. Suggestions for log files to look at, etc.?

Thanks,
Sirius

lshw -class memory

you can also do

yum install hwinfo

then

hwinfo

that will give you physical specs


then you can use

top

or

ps

to see your cpu load in RT.

to show specific cpu stats you can run

top -b -n 1 |grep ^Cpu

have you considered turning off any desktop effects (compiz)?
Its odd because I had a sim issue in ubuntu...you may want to try running it in 2d and see what happens.

I've never used the gnome shell --kde/xfce all the way -- but i've noticed its harder on the ol' cpu no matter what distro im in. There isn't a hard and fast way to fix this kind of problem. Maybe you should make sure all your hardware is functioning -- ram isn't damaged or burned out.

[SiriusStarr]

lshw:

PCI (sysfs)  



  *-firmware              
       description: BIOS
       vendor: Hewlett-Packard
       physical id: 0
       version: 68YVD Ver. F.16
       date: 07/02/2008
       size: 128KiB
       capacity: 960KiB
       capabilities: pci pcmcia pnp upgrade shadowing cdboot bootselect edd int13floppy720 int5printscreen int9keyboard int14serial int17printer acpi usb ls120boot smartbattery biosbootspecification netboot
  *-cache:0
       description: L1 cache
       physical id: 5
       slot: Internal L1 Cache
       size: 64KiB
       capacity: 64KiB
       capabilities: burst internal write-back unified
  *-cache:1
       description: L2 cache
       physical id: 6
       slot: Internal L2 Cache
       size: 4MiB
       capacity: 4MiB
       capabilities: burst external write-back unified
  *-memory
       description: System Memory
       physical id: a
       slot: System board or motherboard
       size: 4GiB
     *-bank:0
          description: SODIMM DDR2 Synchronous 667 MHz (1.5 ns)
          product: JM667QSU-2G
          vendor: 7F4F000000000000
          physical id: 0
          serial: 0007DB62
          slot: DIMM #1
          size: 2GiB
          width: 64 bits
          clock: 667MHz (1.5ns)
     *-bank:1
          description: SODIMM DDR2 Synchronous 667 MHz (1.5 ns)
          product: JM667QSU-2G
          vendor: 7F4F000000000000
          physical id: 1
          serial: 0007DB62
          slot: DIMM #2
          size: 2GiB
          width: 64 bits
          clock: 667MHz (1.5ns)

There doesn't seem to be a "hwinfo" for Fedora. I've checked before, and the CPU is not under any particular load when it freezes. No desktop effects running beyond just Gnome 3.4 stuff. I'll run memtest and make certain the ram is fine.

[cvrpacp]

ya man. I just had a burn out in a usb port myself...which was causing some annoying problems...it took a while to figure out.

see if its using both cores btw if you have a duel/quad core machine...i've seen some situations where you can have

cpu1: 90%
cpu2: 0-2%

part of the reason why I don't use gnome anymore

[SiriusStarr]

No detected errors with memory testing. No issues with pegging one CPU with the other unused. Dunno about USB ports, but they all seem to be functional.

[flyingfsck]

My approach would be to change the DE to something else (LXDE ferinstance) and see whether the problem persists, and if so, change from ethernet to WiFi for networking or vice versa. Other options are to swap the keyboard and mouse. Eventually, I would swap the PSU with one from my junk box and see what happens. Change something and see if you get a clue or two.

[SiriusStarr]

On a laptop, so no keyboard or mouse and can't swap the PSU. Guess I could try switching out to XFCE, but was hoping to find a way to debug the issue. Just not sure what logs to check.