Why is Windows 2000's ACPI support so retarded?

[Kishkumen]

I've been having a problem with my MX300 sound card skipping and choking every time the hard drive was accessed under Windows 2000. I finally came to the conclusion the problem came from the CMD66 IDE controller (on an ASUS CUBX) sharing the same IRQ as the MX300. A few posts suggested switching from ACPI to standard PC. I did this and it was luckily fairly painless. My computer now works SOOOOO much better now than it did before that it makes me want to weep even as a little child. As I understand it this would not normally be a problem as Windows will put the chipset IDE channels on IRQs 14 and 15. However that does me little good since I don't use them anyways. It seems kind of ridiculous to me that Windows 2000 would put every single device under the same IRQ. Why can't it spread the IRQs around a little more? If every single device is under the same IRQ 9 with ACPI does that mean that you've got 10 IRQs just sitting there not being used? I've read the following explanation from Microsoft Explanation from Microsoft on their retarded ACPI implementation but still leaves me less than informed.

 

[AndyHui]

Supposedly Win2K uses IRQ9 in ACPI mode as a gateway to other virtual IRQs above 15. Doesn't always seem to work though.

 

[owensdj]

Kishumen, I don't think it's not Windows 2000's fault that your chipset IDE channels are sharing an IRQ with your PCI devices. I'm running Win2K with the ACPI HAL and my IDE channels use IRQs 14 and 15 with the PCI devices all sharing IRQ 11. Sounds like the problem with either with your mainboard's ACPI implementation or you have a BIOS setting incorrect somewhere.

 

[AndyHui]

owensdj: the CMD controller is counted as an external PCI device and is not assigned to IRQs 14 and 15. That's why he is having these problems.

 

[superbaby]

Wow I didn't know Andy Hui knew anything about computers! Hey he can speak English too!

 

[AndyHui]

superbaby: Er......thanks....um...yeah...