On Sat, 21 Oct 2000, Michael O'Donnell wrote:
>
>
> Is there something (other than the kernel sources)
> that I can read in order to understand the background
> to the current state of PCI handling? I'm asking
> because I (think I) have found an interrupt handling
> bug that derives from uncoordinated management of
> PCI config info, but I don't want to proclaim that
> Linux is broken if the real problem is just a lack
> of understanding on my part.
>
> Here's what I'm tryng to understand: in 2.2.X
> in pcibios_fixup_devices() [and apparently in
> pcibios_fixup_irqs() in 2.4.0test8 as well] we run
> through the list of PCI devices (as represented
> by the in-kernel data structures) looking in each
> device structure for its IRQ, if any. We then
> calculate new IRQ values (suitable for use with the
> I/O-APIC?) and write those new values back into
> the corresponding structure. Later on, various
> drivers use code like pcibios_read_config_byte()
> to query the IRQ value for use during setup of
> their interrupt handlers.
>
> The problem I'm seeing is that at least one driver
> has signed up to handle the wrong IRQ because,
> when it queried that PCI config value, it went
> back and got it from PCI config space rather
> than from the in-kernel data structures where the
> (correct) recalculated value had been stored. So,
> I'm wondering if our Official Approach is to always
> query the in-kernel data structures which have
> been setup so nicely for us, or are we supposed
> to obtain (some or all of) that sort of info from
> PCI space? Or is this all just a bleeding mess?
Correct. The official way is to quiery kernel data structures rather than
peek directly into PCI config space. Which driver (in 2.4) do you
manipulating irq values from config space?
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:17 EST