Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262803AbUJ1HD1 (ORCPT ); Thu, 28 Oct 2004 03:03:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262827AbUJ1HD1 (ORCPT ); Thu, 28 Oct 2004 03:03:27 -0400 Received: from mx1.elte.hu ([157.181.1.137]:62391 "EHLO mx1.elte.hu") by vger.kernel.org with ESMTP id S262803AbUJ1HDA (ORCPT ); Thu, 28 Oct 2004 03:03:00 -0400 Date: Thu, 28 Oct 2004 09:03:57 +0200 From: Ingo Molnar To: Mark_H_Johnson@Raytheon.com Cc: Karsten Wiese , Bill Huey , Adam Heath , "K.R. Foley" , linux-kernel@vger.kernel.org, Florian Schmidt , Fernando Pablo Lopez-Lezcano , Lee Revell , Rui Nuno Capela , Thomas Gleixner , Michal Schmidt Subject: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Message-ID: <20041028070357.GC10488@elte.hu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-2.201, required 5.9, BAYES_00 -4.90, SORTED_RECIPS 2.70 X-ELTE-SpamLevel: X-ELTE-SpamScore: -2 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1726 Lines: 33 * Mark_H_Johnson@Raytheon.com wrote: > I am aware of slow responses normally during tests. However the audio > test should only use one CPU out of two. The other CPU is busy as well > with a cpu burner (nice 10) but that should leave me CPU cycles to > move the mouse, swap windows, etc. The "lock up" I saw this time was > a lot more severe (no mouse motion for several minutes at a time). I > knew the system was still running since the audio continued to play. the way i typically debug such scenarios is to set up a separate 'highprio console' of some sorts. E.g. log in via the network from another box and make sure all processing of that console is SCHED_FIFO. (in the network case that would mean the network IRQ, ksoftirqd, sshd, login and bash.) Such a 'highprio console' should have a higher priority than any other task in the system. If you run alot of stuff in it then it will surely disturb your measurements (and largely invalidate them), but otherwise it can be useful to have it around just in case you experience a lockup that you suspect to be some sort of livelock or starvation. Whenever the lockup happens, check out what's going on, via the highprio console. another useful 'highprio console' is the text console itself - in this case only login and bash has to be chrt-ed, and the runtime impact on the test is smaller as well. This is only useful if you can start your 'bad' workload over ssh or via networked X. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/