OSDev.org

Hi, I have just discovered that the IRQ I thought was correct is incorrect.
I would like to know how to get the IRQ that is assigned to my PCI Ethernet card.

Alistair

You can find it here: http://wiki.osdev.org/PCI#IRQ_Handling

I was looking at Interrupt Line @ 3C.
Is this correct?
The interrupt being fired is 0x14, Interrupt Line @ 3C is 0x0B

Hi,

Nable wrote:

tsdnz wrote:Hi, I have just discovered that the IRQ I thought was correct is incorrect.
I would like to know how to get the IRQ that is assigned to my PCI Ethernet card.

You can find it here: http://wiki.osdev.org/PCI#IRQ_Handling

Also; if the device supports MSI (which is very likely for modern hardware); then you can tell it to use any interrupt vector/s you feel like (as long as nothing else is using those interrupt vectors); instead of trying to figure out which PIC or IO APIC input it uses.


Cheers,

Brendan

Just read your MSI post. http://forum.osdev.org/viewtopic.php?f=1&t=16007.
It sounds like a tricky setup.
I might try to figure out the IRQ

Having another look at MSI. Does the device, in my case Ethernet, need to know MSI?

EDIT: or have the ability to write to an address?

Is this how it works?

Hi,

tsdnz wrote:Having another look at MSI. Does the device, in my case Ethernet, need to know MSI?

Yes, if the device itself doesn't support MSI then you can't use MSI (e.g. it won't have the registers you need to configure it in the device's PCI configuration space).


Cheers,

Brendan

Thanks, this MSI looks really neat, what a great idea.
Keen to get an Ethernet card with it.
Any suggestions?

Also, any pointer how I find the IRQ for my Ethernet card?

Hi,

tsdnz wrote:Thanks, this MSI looks really neat, what a great idea.
Keen to get an Ethernet card with it.
Any suggestions?

I'd be surprised (in a bad way) if it's still possible to buy an ethernet card that doesn't support MSI.

tsdnz wrote:Also, any pointer how I find the IRQ for my Ethernet card?

The alternatives are:

• Use polling instead. This is almost always a very bad idea.
• Use the PIC chips "as is". In this case you can get the "PIC IRQ number" from the device's PCI configuration space. This won't work well for single-CPU as it fails to avoid IRQ sharing; and will be much worse for multi-CPU (as the PIC chips can't handle that). Also, if I were a chipset designer the PIC chips would be near the top of my "obsolete crud to forget about when we've finished moving to UEFI" list; and I definitely wouldn't expect the PIC chips to exist forever.
• Use the PIC chips and the "PCI IRQ routers" to change how PCI IRQs are mapped to PIC inputs. This solves nothing and just complicates things more (mentioned for completeness only).
• Use the IO APICs and the "Multi-Processor Specification" table to determine which IO APIC input the device is connected to. This is deprecated (replaced with ACPI) so...
• Use the IO APICs and ACPI to determine which IO APIC input the device is connected to. This involves implementing or porting an AML interpreter, and is a massively over-complicated nightmare.
• Use the IO APICs and have a "motherboard drivers" for each different motherboard that can tell you which IO APIC input each device uses. Writing all the motherboard drivers will cost a significant amount of time.
• Use the IO APICs and design a clever "IO APIC input auto-detection" scheme. This is likely to have many pitfalls.
• Use MSI. This won't work on ancient hardware.

If you choose one of these alternatives, then your choice will be wrong - eventually, you will need to support multiple alternatives (not one) and (e.g.) have code that selects which option/s to use at run-time based on what the hardware supports.


Cheers,

Brendan

I feel like a kid at a candy store.
So much has changed since I was last programming OS level.
Just great, what advancements, very exciting.

About to see if the card I just brought has MSI.

Thanks.

EDIT: It does in deed!!

Hi, Is the latest PCI, PCI Express?