Messages in this thread | | | Subject | Re: [PATCH 1/5] stack overflow safe kdump (2.6.16-rc1-i386) - safe_smp_processor_id | From | (Eric W. Biederman) | Date | Wed, 25 Jan 2006 03:27:17 -0700 |
| |
Fernando Luis Vazquez Cao <fernando@intellilink.co.jp> writes:
> On Wed, 2006-01-25 at 09:07 +0100, Arjan van de Ven wrote: >> On Tue, 2006-01-24 at 23:59 -0800, Andrew Morton wrote: >> > Andi Kleen <ak@suse.de> wrote: >> > > >> > > On Wednesday 25 January 2006 08:10, Andrew Morton wrote: >> > > >> > > > It assumes that all x86 SMP machines have APICs. That's untrue of > Voyager. >> > > > I think we can probably live with this assumption - others would know >> > > > better than I. >> > > >> > > Early x86s didn't have APICs and they are still often disabled on not so >> > > old mobile CPUs. I don't think it's a good assumption to make for i386. >> > > >> > >> > But how many of those do SMP? >> >> even on SMP boxes you regularly need to (runtime) disable apics. Several >> boards out there just have busted apics, or at least when used with >> linux. "noapic" is one of the more frequent things distro support people >> tell customers over the phone.... > Checking whether ioapic_setup_disabled is set should suffice, right? > Does the patch below look good?
Actually hard_smp_processor_id should only care about local apics. Disabling the io_apics should have no affect, on this code path.
So I believe testing for io_apics being enabled is actively wrong.
If the local apics are disabled the feature flag should be cleared, and we are uniprocessor anyway.
Eric - 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/
| |