Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!

And now /proc/cpuinfo and cpuid both show APIC support.

Removed/replaced power, triggered lid-switch/battery-status/etc with no
issues.  (The only thing that caused trouble was Fn-F10, the "eject cd"
button.  Never tried it under Linux before, and the cd isn't in it at
the moment anyway, so I'm betting thats unrelated. But it did cause a
lockup that even sysrq couldn't recover.)

Not 100% clear on what the APIC does, but I'm not sure its doing it ;) 

PCI: Using ACPI for IRQ routing <-- shouldn't this be missing if the
APIC is in use?

(Full dmesg attached, for those who are curious - the unknown-scancode
is for the various laptop buttons - bright/dim, vol, media, battery,
etc.  Except for the volume buttons the only ones that work are the ones
that directly hit the hardware, ala bright/dim.)

Also, for others with an I8500 who might read the dmesg log, don't get
excited; thats not the wireless card they sell (Broadcom 802.11g) its
the older one (Orinoco 802.11b).  They'll sell you one for about $70,
goes right in in place of the unsupported one.

>From single-user:
# cat /proc/interrupts
           CPU0
  0:       8716          XT-PIC  timer
  1:        572          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          4          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 11:         20          XT-PIC  usb-uhci, usb-uhci, usb-uhci, ehci-hcd,
eth0
 14:       2610          XT-PIC  ide0
NMI:          0
LOC:       8649
ERR:          0
MIS:          0


After booting, building/installing alsa-modules, getting into X, etc etc
etc..
           CPU0
  0:     121238          XT-PIC  timer
  1:       6472          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          4          XT-PIC  rtc
  9:          9          XT-PIC  acpi
 11:     125522          XT-PIC  usb-uhci, usb-uhci, usb-uhci, ehci-hcd,
eth0, PCI device 104c:ac44 (Texas Instruments), Texas Instruments
PCI1410 PC card Cardbus Controller, orinoco_cs, Intel 82801DB-ICH4
 12:      20693          XT-PIC  PS/2 Mouse
 14:      28381          XT-PIC  ide0
NMI:          0
LOC:     121201
ERR:          0
MIS:          0



On Mon, 2003-05-26 at 05:21, mikpe@csd.uu.se wrote:
> On 26 May 2003 01:31:41 -0400, Disconnect <lkml@sigkill.net> wrote:
> >> OK, I put together a kernel that had the Latitude blacklist commented out,
> >> and it comes up with:
> >> 
> >> No local APIC present or hardware disabled
> >> Initializing CPU#0
> >> 
> >> So add the Latitude C840 to the "known b0rken" list.
> >
> >Ditto the Inspiron 8500 - no apic at all (which is different from
> >known-broken, since nothing bad happened.)  
> ...
> >Perhaps just a comment above those entries:
> >/* Latitude C840 and Inspiron 8500 have no APIC support in hardware */
> 
> If these machines are P4-based, then I bet they do have local APICs.
> However, if the BIOS boots the kernel with the local APIC disabled
> on a P4, we (apic.c) don't try to enable it. The logic behind that
> is that "modern" BIOSen _should_ boot with it enabled, unless they're
> horribly broken.
> 
> So apply the patch below and try the "can we get the machine to hang"
> checklist again.
> 
> /Mikael
> 
> --- linux-2.5.69/arch/i386/kernel/apic.c.~1~	2003-04-20 13:08:15.000000000 +0200
> +++ linux-2.5.69/arch/i386/kernel/apic.c	2003-05-26 11:11:19.000000000 +0200
> @@ -617,7 +617,7 @@
>  		goto no_apic;
>  	case X86_VENDOR_INTEL:
>  		if (boot_cpu_data.x86 == 6 ||
> -		    (boot_cpu_data.x86 == 15 && cpu_has_apic) ||
> +		    (boot_cpu_data.x86 == 15) ||
>  		    (boot_cpu_data.x86 == 5 && cpu_has_apic))
>  			break;
>  		goto no_apic;
-- 
Disconnect <lkml@sigkill.net>