That was the approach I wanted to use in the first place to deal with the
broken local apic in vmware 2.0.4. See the thread (which is unfortunately
broken -- the followup must not have included a References: header back to
the my original message):
http://www.ussg.iu.edu/hypermail/linux/kernel/0305.3/0907.html
The thread can be picked up again in this message:
http://www.ussg.iu.edu/hypermail/linux/kernel/0305.3/0995.html
> "nolapic" is
> simply a workaround for the absence of this DMI data.
Unfortunately, VMware 2.0.4 does not have any DMI data to identify it by.
the search for _DMI_ between 0xF0000 and 0xFFFFF finds nothing. I dunno
if this is valid for proving or disproving the presence of DMI data, but:
# dmidecode
# dmidecode 1.8
BIOS32 Service Directory present.
Calling Interface Address: 0x000FD8C0
PNP 1.0 present.
Event Notification: Not Supported
Real Mode Code Address: F000:AEA5
Real Mode Data Address: 0040:0000
Protected Mode Code Address: 0x000FAEC3
Protected Mode Data Address: 0x00000400
PCI Interrupt Routing 1.0 present.
Table Size: 0 bytes
Router ID: ff:1f.7
Exclusive IRQs: None
> Notice how silent the Inspiron 8k users are now that the DMI black
> list is implemented...
:-) I like the approach, it just doesn't always apply, thus the need for
kernel commandline args.
b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/