ACPI question...

[Duty]

A question hit me yesterday about ACPI hardware pooling. In my comp (dual celery, w2k pro) my IRQ list has numbers greater then 15. I thought this was the norm for the ACPI setup until I noticed a few work computers with ACPI kernal running but having IRQ conflicts. Is there a special setting I am not aware of? I've been looking around the internet and here in the forums and I get some good info on what ACPI is and how to get the kernal running but in at least one case, here, there is still IRQ conflicts.
Again just wondering if there is something I missed along the way. Lastly can you get this runnig on the VIA chipset motherboards?
Thanks much...

Jeff



------------------
Remember when naps were a bad thing?

-------------------------------
You stop learning when you are die, and some people just don't know the're dead yet!
-------------------------------
ABIT BP6 - 2 x Celeron 500 - 256MB Ram - MX300 - 3Com 509c - Creative PC DVD 6x - G400 DH - DSL (True Love Here) - Win98 se - Win 2000 pro

[SCompRacer]

Jeff, as far as ACPI and Via go, do you mean getting STR (Suspend To Ram) to work?


------------------
ABIT KT7A, RAID 0 * 900MHz Athlon T'bird, 133/33 @ 7.5 for 1000 * 256MB Crucial 7E PC/133 RAM * Two 30GB IBM 75GXP's * The Rest

[Ali]

You have more than 16 IRQs because you have 2 CPUs.

An IRQ is a request made by a program to use some CPU cycles. Since you have 2 CPUs and you are using an OS that supports multi threading, you can have theoretically up to 32 IRQs, though in practice you will get far fewer. Each CPU needs to talk to each other, so there are 2 IRQ gone, and motherboard resources will use a few also.

What ACPI does is share a single IRQ with multiple programs and sort out what program requested cycles, and what program didnt, then share out the CPU time the way it wants. This isnt 100% correct, but is the main idea.

I always thought it was hardware that needed IRQs, but its actually the drivers that controls the hardware. Also, firmware counts as a program in this situation.

Strange, but I was just reading about this last night.

Ali

[xortam]

Go back and read some more Ali. There are both HW and SW interrupts. IRQs are HW interrupts. They both cause the CPU to transfer control to an ISR (Interrupt Service Routine) which will process the interrupt (set flags or state variables, transfer data, etc.) and then reenable interrupts before returning control to the interrupted task.

[Duty]

Thanks everyone. This helps...


Jeff

[kjliew]

The reason you're having more than 16 IRQs is because you're running a dual-processor system. All Microsoft SMP capable OSes (WinNT/2k) will only work with APIC (Advanced PIC) if you have more than 1 CPU. Legacy dual-8259A PIC is not capable of SMP.

ACPI has nothing to do with how OS handles interrupts, it only changes how OS allocates resources to peripherals (IRQs, DMA, I/O and memory).

[Ali]

Xortam, when a piece of hardware needs some CPU time, the FIRMWARE on that piece of hardware is what sends the interupt request.

That is assuming its not a WIN modem or something similar.

I was trying to make it simple before by clumping both firmware and software as the same thing. That was how it was explained in the book I was reading, and it made sense to me.

If you note, I do say its not 100% correct.

Ali

[xortam]

Ali ... hope were not beating this side issue to death but whether its the HW directly or firmware invoking the interrupt, the request comes from a device versus a SW interrupt which is invoked by a process running under the CPU. For example, a keyboard key depression causes an interrupt to be sent via the keyboard controller (IRQ 1, interrupt 9) and the BIOS handles the interrupt by setting internal flags (e.g. shift codes) and buffering the key make code. The BIOS then resets the controller and reenables interrupts and resumes control to the task that was interrupted by this HW event. An application may want to poll for keyboard input and invoke the OS to retrieve keyboard status/data via SW interrupt 16. The BIOS gains control via this SW interrupt, checks its internal states and key data and passes the information while reenabling interrupts and returning control to the invoking task. The keyboard controller issues a HW interrupt while the application issues a SW interrupt.