I read somewhere (actually have the article saved someplace, but no clue where lol) that some function call lines like blablabla_blabla-X, blablabla_blabla-Y, blablabla_blabla-Z are in a different order in the newer Debian thingy, & when one is called before the other, then the other won't load devices properly... or something to that effect.

(Went away from the computer for a few minutes)

Ok... so i didn't save the url to the post like i thought i did. Here's what I saved:

Bug#258061: ACPI initialization hangs on Compaq Presario 2100
Ok I verified that:

* This issue is yet valid for current 2.6.8 with acpi=on
* It's valid for 2.4 series up to 2.4.27 with acpi=on
* Patch proposed in 2.6.8 does not solve the issue, so it can be removed.

The only workaround in all cases is the 'nolapic' boot param.

--
Francesco P. Lovergine
Is there a problem with the idea of "turn off APIC timer before ACPI
initialization and then turn back on after ACPI initialization
finishes"? This is exactly what the tiny patch I've sent does. I would
agree that 'nolapic' boot param "solves" the problem, but IMHO the
idea above is clearer and works perfectly.

Thanks,

Bruno.
--
Bruno Diniz de Paula
The idea is clear, but that patch does not work on the 2100 I tried.
It was already implemented in current 2.6.8 AFAIK and it has exactly
the same problem of hang up.

--
Francesco P. Lovergine
When the patch you mentioned was not applied, I could make it work
with any kernel version by simply adding a 'disable_APIC_timer' in the
beginning of acpi_bus_init, and a 'enable_APIC_timer' in the end of
this function.

By the way, what is Local APIC for? What do I lose having Local APIC disabled?

Thanks,
Bruno.

--
Bruno Diniz de Paula
Find it in kernel sources:

A local APIC (Advanced Programmable Interrupt Controller) is an
integrated interrupt controller in the CPU. If you have a single-CPU
system which has a processor with a local APIC, you can say Y here to
enable and use it. If you say Y here even though your machine doesn't
have a local APIC, then the kernel will still run with no slowdown at
all. The local APIC supports CPU-generated self-interrupts (timer,
performance counters), and the NMI watchdog which detects hard lockups.

The processor local APIC is of fundamental importance in SMP and RT
environments to manage correctly I/O and and internal interrupts, timing
and so. You can live without on uniprocessor systems.
P5 did not have lapic indeed. If I remember correctly first multi-proc
board had PPro which was the first with a lapic...

Anyway tnis is the 'missing pointer' for the issue on LKML:

***.ussg.iu.edu/hypermail/linux/kernel/0401.2/1525.html (replace '*' with 'w')

And it seems simply missing in debian sources. So the fix by Christopher
was different (and unuseful for this issue).

--
Francesco P. Lovergine
More info: bugzilla.kernel.org/show_bug.cgi?id=1269

This is the same patch (early init) proposed by Chris and apparently does
not solve the problem for all models. At least not for Compaq AMD-based 2100.
As in many cases for ACPI related issues, it's anyway caused by a buggy
BIOS. The only detail is that it's a damn common problem :-/

--
Francesco P. Lovergine
Found the URL via Google
lists.debian.org/debian-kernel/2004/09/msg00086.html

(Jan 25th 2013)