RE: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeonprocessors in EM64T mode (x86_64)

> 
> A run-time solution would be preferable to adding a config 
> option that only changes the default behaviour.
> 
> In general, the more config options, the more kernels we 
> force distros to build and support.  We really want to going 
> the other way and simplifying, when possible.


Len and Zwane, I sure agree with you. I will take the config option out.
Would the APIC version be a good criteria to make a run-time decision
with Xeons? I know that everything Intel that can run EM64T has front
side bus (APIC version >= 20?). And I guess the boot parameter can still
be useful?

Thanks,
--Natalie 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• Follow-Ups:
  • RE: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeonprocessors in EM64T mode (x86_64)
    • From: "Maciej W. Rozycki" <[email protected]>

• Prev by Date: Re: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeon processors in EM64T mode (x86_64)
• Next by Date: RE: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeonprocessors in EM64T mode (x86_64)
• Previous by thread: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeon processors in EM64T mode (x86_64)
• Next by thread: RE: [patch 1/1] Do not enforce unique IO_APIC_ID for Xeonprocessors in EM64T mode (x86_64)
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]