[lkml]   [2006]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Bugme-new] [Bug 7495] New: Kernel periodically hangs.

    > 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)
    Test the interaction between Linux and your BIOS via

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-12 14:21    [W:0.038 / U:5.148 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site