lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/5] stack overflow safe kdump (2.6.16-rc1-i386) - safe_smp_processor_id
From
Date
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/

\
 
 \ /
  Last update: 2006-01-25 11:30    [W:0.036 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site