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

BOUNCE rtl@rtlinux.org: Approval required: Non-member submissionfrom [Paolo Mantegazza <mantegazza@aero.polimi.it>] (fwd)



>From owner-rtl Wed May 16 03:40:55 2001
Received: from server.aero.polimi.it (server.aero.polimi.it [131.175.154.199])
	by hq.fsmlabs.com (8.11.2/8.11.2) with ESMTP id f4G9esr05214
	for <rtl@rtlinux.org>; Wed, 16 May 2001 03:40:55 -0600
Received: from aero.polimi.it (mante@pc-mante.aero.polimi.it [131.175.154.67])
	by server.aero.polimi.it (8.11.0/8.11.0) with ESMTP id f4G9a8303285;
	Wed, 16 May 2001 11:36:08 +0200 (MEST)
Sender: mante@aero.polimi.it
Message-ID: <3B0232F3.C0668221@aero.polimi.it>
Date: Wed, 16 May 2001 09:57:39 +0200
From: Paolo Mantegazza <mantegazza@aero.polimi.it>
Organization: Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.4.0-test1 i686)
MIME-Version: 1.0
To: kumsta christophe <christophe.kumsta@free.fr>, rtl@rtlinux.org
Subject: Re: [rtl] LOCKUP on CPU
References: <20010516090630.938041028C7@postfix1-2.free.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

kumsta christophe wrote:
> 
> 16/05/2001 08:22:53, Paolo Mantegazza <mantegazza@aero.polimi.it> wrote:
> >Unfortunately not. I never noticed the kind of mapping you report on my
> >machines. RTAI-24.1.4 should trap traps and skip the nonmaskable
> >interrupts handling. Such a handling in Linux detects possible CPU locks
> >by checking the number of NMIs against the APIC timers one. You can try
> >also adding: append="nmi_watchdog=0"
> >in LILO to see what happens.
> >It disables lock processing through NMI natively in Linux.
> 
> Hi,
> 
> I'm trying to find where the system lock,
> and I found that it locks in rtai.c, line 532 (hard_lock_all() function)
> in the while loop.
> 
> I get the value :
> cpu_own_irq[HARD_LOCK_IPI].dest_status = 0x000000000
> cpu_online_map = 0x00000003
> global.locked_cpus = 0x80000001
> 
> I agree with dest_status and cpu_online_map, but I don't understand the
> bit 31 in locked_cpus ... is this the 2nd locked cpu ??

There seems to be something related to the mapping of CPUS.
cpu_online_map = 0x00000003 should never produce an 8 in
global.locked_cpus, but 3 at most. At least it has been so till now, on
all the machines I used. It is likely that it must be fixed by a
cascaded double mapping.

The 1 in bit 31 is simply "the lock". 

Ciao, Paolo..