[sf-lug] Pointers for how to track down source of system hang

[Mark K. Zanfardino]

Charles,

The CPU is an AMD Athlon X2 (64-bit) but I'm running the 32-bit version 
of Kubuntu.  I had considered a hardware issue.  I've run memtest86+ in 
order to be sure that I hadn't any defective RAM.  The memtest returns 
all clear.  Which is not to suggest that something else might not be flaky.

I hadn't been aware of the specific site you listed, so I will read that 
next and see if I can gain any deeper understanding of debugging system 
crashes.

Any other feedback anyone else may care to offer concerning other files 
I should check or other means by which I can gain more insight will be 
greatly appreciated.

Cheers!

Mark

Charles N Wyble wrote:
> Kristian,
>
> I can say unequivocally that I *am* using the proprietary nvidia 
> driver.  This is to provide the 3D support that Compiz requires.  I can 
> certainly try running the system without it installed for some period of 
> time.
>
> [Charles N Wyble] 
>
> I believe in a previous message you stated that you saw the hang even with
> Compiz turned off? Is the hardware 32 or 64 bit and if 64bit are you running
> a 
> 32 or 64 bit version of Ubuntu? 
>
>
> As to the gap time between faults, I can only give a rough estimate, as 
> it's variable.  Some times the system hangs multiple time in one day 
> with a gap time ranging from < an hour to > 4+ hours.  However, other 
> times the system remains stable for several days.
>
> [Charles N Wyble] 
>
> This sounds like it may be a hardware issue especially the fact that it
> doesn't respond to sysrq sequences. Although this may be due to the kernel
> not supporting those. 
>
> May I recommend the following page:
> https://help.ubuntu.com/community/DebuggingProcedures
>
> also 
>
> https://wiki.ubuntu.com/LinuxKernelCrashDumpSpec 
> http://packages.ubuntu.com/gutsy/utils/crash
> https://wiki.ubuntu.com/KernelTeamBugPolicies
>
> may be of interest.
>
> Installing the network crash dump utility is highly recommended. 
> Also see 
> http://packages.ubuntu.com/dapper/devel/lcrash
>
>
> You may also find Oprofile useful.
>
> I know lots of info. :) 
>
> Linux crash reporting/handling isn't the best unfortunately. 
>
>
>
>
>
>
>
> As of today I've gone back to running without Compiz but have re-enabled 
> the audio (it's a necessity for some of the development work I'm doing) 
> and thus far it's remained stable, but that's no indication of whether 
> or not it will remain so.
>
> [Charles N Wyble] 
>
> Interesting. Are you running a Xen kernel by chance? 
>
>
> As an aside, it has at times remained very stable over as long as a week 
> or more with both Compiz running and the sound driver installed, which 
> makes me think it's going to be something else.  The key for me is to be 
> sure I'm checking all relevant logs and that I have all possible logging 
> enabled.  I've stated the four (4) files I'm aware of, but would love 
> feedback on other sources of information.
>
>  [Charles N Wyble] 
>
> Well the system logs are useful for a lot of things. However a kernel
> crash (called an oops) requires a fair amount of special monitoring
> tools. I wish all the distros came with it turned on and configured
> out of the box. 
>
> Sorry for the brain dump format of this e-mail. I hope to get the
> Info out there and spark more discussion. 
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>
>
>