[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: