Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 28 Jul 2002 17:31:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 28 Jul 2002 17:31:56 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]:19330 "EHLO e35.co.us.ibm.com") by vger.kernel.org with ESMTP id ; Sun, 28 Jul 2002 17:31:56 -0400 Date: Sun, 28 Jul 2002 14:33:19 -0700 From: "Martin J. Bligh" Reply-To: "Martin J. Bligh" To: Zwane Mwaikambo , William Lee Irwin III cc: Robert Love , Andrew Morton , Ravikiran G Thirumalai , linux-kernel@vger.kernel.org, lse , riel@conectiva.com.br, Rusty Russell Subject: Re: [Lse-tech] Re: [RFC] Scalable statistics counters using kmalloc_percpu Message-ID: <490876873.1027866798@[10.10.2.3]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2020 Lines: 48 > Since you can only have 4 bits for your IOAPIC ID, you need to stuff them > all into the 4 bit address space, looking at the IDs there should be > plenty space for 8 IOAPICs in the 4 bit region. Well, there's 16 cpus and 8 ioapics to theoretically go into that space. The trouble is that it's not really one physical address space globally, it's one per node, so the whole thing's a total hack. > Another funny, is how come > it tries to reassign IDs for 12 IOAPICs? unless it picked up more from the > proprietory vendor section of mp tables seeing as it only picked up 8 at > boot, i think that code might need a once over. The strangest thing to me is that all the IDs are 0, when they weren't to start with. Something's corrupting memory ... I'd happily blame my own code, but allegedly this has happened without CONFIG_MULTIQUAD too. > if (clustered_apic_mode) > /* We don't have a good way to do this yet - hack */ > phys_id_present_map = (u_long) 0xf; > > urgh... Yeah, OK ... that's my fault. This is the physical space, and we should really look up the physical ID of each device and put into into a per-quad mapping. But that works just fine as a hack without the NR_CPUs parameter, and it's only an exclusion thing anyway, so even if a CPU doesn't come online it's correct enough. The real question is why does this work if NR_CPUS is 32, but not if we take it down somewhat? Likely one of the arrays is getting overshot, but we need to do some debug to find out where & why. > Overrall i think arch/i386/kernel/io_apic.c needs a looking over. No denying that, but it takes a fearless man to stare into the eyes of Intel's IOAPIC and survive ;-) I barely survived the last time, and am not desperately keen to do it again ... M. - 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/