Paul Durrant wrote:
On 22/05/07, Andrew Gallatin <[EMAIL PROTECTED]> wrote:
Since it is MSI, you might want to check the MSI related fields in
your device's config space, and after re-enabling, see if MSI is
enabled and has the same address/data as before you disabled your
interrupt.
Yep - that's a good idea. So.. more ioctls; whilst the interrupts are
working I see my MSI capability as:
[0x50]: 05 60 97 00 00 00 e0 fe 00 00 00 00 62 00 00 00
So, I read that as message data 0x62 to address 0xfee00000 and sure
enough, as usual, ::interrupts shows:
89 0x62 6 PCIe Edg MSI 0 1 - sfxge_intr_msi
90 0x63 6 PCIe Edg MSI 0 1 - sfxge_intr_msi
I now disable and re-enable. My MSI capability is now:
[0x50]: 05 60 96 00 00 00 e0 fe 00 00 00 00 62 00 00 00
so no change,
not quite; third byte changes from 97 to 96. I didn't look up what that means.
bur ::interrupts shows:
89 0x61 6 PCIe Edg MSI 1 1 - sfxge_intr_msi
90 0x62 6 PCIe Edg MSI 1 1 - sfxge_intr_msi
so the base vector is now *wrong*. I guess this is the problem
although I don't quite understand why sfxge_intr_msi() is no longer
being called at all. I would have thought it would just get called
with the wrong context arg2, but that does not seem to be the case.
Paul
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
