Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261386AbVCaMWQ (ORCPT ); Thu, 31 Mar 2005 07:22:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261390AbVCaMWQ (ORCPT ); Thu, 31 Mar 2005 07:22:16 -0500 Received: from ms-smtp-03.nyroc.rr.com ([24.24.2.57]:61180 "EHLO ms-smtp-03.nyroc.rr.com") by vger.kernel.org with ESMTP id S261386AbVCaMWL (ORCPT ); Thu, 31 Mar 2005 07:22:11 -0500 Subject: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07 From: Steven Rostedt To: Ingo Molnar Cc: Esben Nielsen , LKML In-Reply-To: <20050331110330.GA24842@elte.hu> References: <1112212608.3691.147.camel@localhost.localdomain> <1112218750.3691.165.camel@localhost.localdomain> <20050331110330.GA24842@elte.hu> Content-Type: text/plain Organization: Kihon Technologies Date: Thu, 31 Mar 2005 07:22:02 -0500 Message-Id: <1112271722.3691.218.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1974 Lines: 49 On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote: > * Steven Rostedt wrote: > > > Well, here it finally is. There's still things I don't like about it. > > But it seems to work, and that's the important part. > > > > I had to reluctantly add two items to the task_struct. I was hoping > > to avoid that. But because of race conditions it seemed to be the only > > way. > > well it's not a big problem, and we avoided having to add flags to the > rt_lock structure, which is the important issue. > > your patch looks good, i've added it to my tree and have uploaded the > -26-00 patch. It boots fine on my testbox, except for some new messages: > > knodemgrd_0/902: BUG in __down_complete at kernel/rt.c:1568 > [] dump_stack+0x23/0x25 (20) > [] down_trylock+0x1fb/0x200 (48) > [] nodemgr_host_thread+0xd0/0x17b (48) > [] kernel_thread_helper+0x5/0xb (136249364) > --------------------------- > | preempt count: 00000001 ] > | 1-level deep critical section nesting: > ---------------------------------------- > .. [] .... print_traces+0x1b/0x52 > .....[] .. ( <= dump_stack+0x23/0x25) > > this goes away if i revert your patch. It seems the reason is that > trylock hasnt been updated to use the pending-owner logic? Hmm, The pending owner logic in __down_trylock uses the grab_lock function. It doesn't need the capture_lock since it never sleeps. I'm downloading your 42-00-experimental now and installing it to see if I can get the same message. Did you try the patch against 41-11? Maybe the patch didn't go in so smoothly. Anyway, I'll take a look at it now and let you know what I find. Thanks, -- Steve - 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/