Re: Frequent system crash -- with gcc3.2 (?)
On Fri, 2003-03-14 at 22:47, Kevin Buhr wrote:
> The comments H. S. Teoh made are technically right. However, when you
> see an unkillable process permanently stuck in the "R" state on a dual
> processor machine, it's often because one of the processors went off
> into user space and never came back. If, when this happens, you "cat
> /proc/interrupts" a few times, you'll discover that one of the columns
> of numbers remains fixed---that processor has simply died.
This is what is happening:the column for CPU0 does not change.
> If the processor dies in the kernel while holding a lock, the other
> processor will eventually freeze waiting for that lock. Depending on
> how this happens, the waiting processor will normally still respond to
> interrupts, so you'll be able to use Alt-SysReq keys and such. If you
> try Alt-SysReq-B, it'll eventually hang as the kernel tries to regain
> control of the other (dead) processor.
Thanks for this information; it exactly matches my problem.
> Try running your compilations with only one of the two processors
> installed. You may find that one of them is flakey.
Since it is CPU0 every time, I guess the question is answered. Is there
any generic way to know which processor on the board is CPU0?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Thy word have I hid in mine heart, that I might not
sin against thee." Psalms 119:11
Reply to: