Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756001AbYCCNle (ORCPT ); Mon, 3 Mar 2008 08:41:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753072AbYCCNl0 (ORCPT ); Mon, 3 Mar 2008 08:41:26 -0500 Received: from mx2.compro.net ([216.54.166.4]:42191 "EHLO mx2.compro.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752156AbYCCNl0 (ORCPT ); Mon, 3 Mar 2008 08:41:26 -0500 X-IronPort-AV: E=Sophos;i="4.25,438,1199682000"; d="scan'208";a="1800240" Message-ID: <47CBFED1.7090903@compro.net> Date: Mon, 03 Mar 2008 08:36:17 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. User-Agent: Thunderbird 2.0.0.9 (X11/20070801) MIME-Version: 1.0 To: Steven Rostedt CC: Jon Masters , Mark Hounschell , linux-kernel , Ingo Molnar , Thomas Gleixner Subject: Re: 2.6.24-rt1 IRQ routing anomaly References: <47BD6802.60604@cfl.rr.com> <47BD7D09.9050106@compro.net> <1204518711.22885.68.camel@perihelion> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1679 Lines: 41 Steven Rostedt wrote: > On Sun, 2 Mar 2008, Jon Masters wrote: >> On Thu, 2008-02-21 at 10:08 -0500, Steven Rostedt wrote: >>> On Thu, 21 Feb 2008, Mark Hounschell wrote: >>>>> To prove this is the problem, boot with noapic in the kernel command line. >>>>> 1) the problem should disappear. >>>>> 2) (I'm betting) you see that the eth and EMU10K1 share the same >>>>> interrupt line. >>>>> >>>> Yep, you were right. They do share the same IRQ and the problem does go away. >>>> Unfortunately I can't run this machine with noapic. I need irq affinity. >>>> >>> Thanks for verifying. OK, I'll see if I can get the workaround on i386. >> What's the situation with this one? Want me to look at it? > > Jon, > > The board Mark has may just be some cheap hardware. It would be great > that RT would work on all boxes, but I'm not sure we want to spend time on > "broken-by-design" hardware while there's bigger fish in the sea to catch. > > The current workaround is just use noapic, although I do understand > that's not good enough for Mark. But I'm sure Mark has other hardware > he could use ;-) > > -- Steve > > Steve is correct. I have plenty of other choices. Steve, you mentioned, a "work around" is in -rt3. My only concern is does the current "work around" for other hardware really work or may I see this again with other "non cheap" hardware? Is there a known list of hardware this problem is seen on? Thanks Mark -- 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/