> Some APIC-related bugs in the kernel Bugzilla that have been reported or
> confirmed during the last 12 months (I only looked at "apic" in the
> subject, there might be more related bugs in the Bugzilla):
>
> #5038 Fast running system clock with IO-APIC enabled
This is a UP machine. NotInteresting(tm) wrt APIC.
> #5303 AMD64 Erratum: Should not enable C2 when using APIC
This is clearly not a linux issue but a hardware bug, as the title says
> #5565 Guess of i386 APIC PTE area scribble
this is only on one machine and a "special case"; not ruling out
anything fundamental but..
> #6404 APIC error on CPU0: 40(40)
This bug is a mess though; many different people seeing a symptom of an
apic error, and all jumping in assuming they see the same problem...
Also it's afaik only a message and not (yet) fatal in any way.
Sometimes apics do this a few times a day, esp when things are getting
hot in the box. Afaik there is then just a resend of the message and
nothing is lost.
> #6748 Clock drifts by 30% for SMP kernel w/APIC
this looks like a totally weird hardware case that probably just wants
to be blacklisted.
> #6859 Linux kernel won't work without "nolapic" passed
weird one, probably a bios issue but it's the opposite of "noapic", and
also this is about local apic not about ioapic. Although they share 4
letters they're entirely different animals.
> #6890 Kernel boot freezes when APIC is enabled & SATA is used
seems to be UP as well but asked for confirmation in the bug (lack of
lots of information here!).
If this isn't UP this could be the first real case of "noapic" in your
entire list...... which isn't too useful.
Maybe we need to get more/any people who see "need noapic on SMP" to
file a bug (and provide a reasonable amount of info)
> >
> > 1) Only care about SMP machines. APIC on true UP (no
> > Hyperthreading/Dualcore) is a thing no hardware vendor tests (Microsoft
> > doesn't use it) and is just too likely to trip up SMM and other bad BIOS
> > stuff.
> > * exception is probably people who don't WANT to use apic but where it
> > somehow gets used anyway; if that happens we probably have the magic
> > bullet that causes the regression :)
>
> On i386, it's a kernel configuration option.
yes but it's generally a bad idea to set it; it only works on some
machines. (and it can't be fixed)
>
> On x86_64, the APIC is currently always enabled even when configuring a
> UP kernel.
I think that's a mistake. But oh well, I suspect in practice ACPI/BIOS
cause it to be turned off automatic most of the time.
>
> > 2) Only care about ACPI using kernels. Non-ACPI uses MPS tables for
> > this, but most vendors hardly maintain those anymore at all and they are
> > generally just /dev/random nowadays
>
> What about non-ACPI SMP?
if the machine is new enough to run ACPI I don't care about the non-ACPI
case; just enable it. Really. On newish machines (and that is 7 years
old or newer) MPS tables are NOT getting much if any attention by the
bios guys. So Linux should use ACPI, and if you deliberately disable
ACPI and THEN hit a problem to a large degree you asked for the problem
in the first place.
Older machines, different story.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
-
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/
[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]
