Hi,
has anyone an idea how the SMP problems could be fixed?
I did some further investigation. When comparing the number of
interrupts with all cores enabled and the interrupts with only one core
enabled it seems like only the IRQ0 changed, the other IRQs and the
total number stays quite the same:
4 Cores:
All IRQ/sec: 493
Masked IRQ/sec: 400
Unknown IRQ/sec: 0
DMA/sec: 400
IRQ-0/sec: 143
IRQ-1/sec: 0
OCERR/sec: 0
PABRT/sec: 0
RIPRR/sec: 0
PPERR/sec: 0
FTRGT/sec: 0
RISCI/sec: 258
RACK/sec: 0
1 Core:
All IRQ/sec: 518
Masked IRQ/sec: 504
Unknown IRQ/sec: 0
DMA/sec: 504
IRQ-0/sec: 246
IRQ-1/sec: 0
OCERR/sec: 0
PABRT/sec: 0
RIPRR/sec: 0
PPERR/sec: 0
FTRGT/sec: 0
RISCI/sec: 258
RACK/sec: 0
So, where might be the problem?
I don't think the IRQ gets lost on the way from the device to the
driver, because only IRQ0 is affected.
I don't think the device or the driver is to slow because it works fine
with only one Core and it also works with
SMP when ignoring the timeout and just read the data at the time the IRQ
should have fired.
Maybe the (cam) locking is faulty (looks fine to me...).
Maybe the IRQ handler gets executed parallel on two cores which leads to
the problem. But then I think this
should be fixed when setting IRQ affinity to only core, but it didn't
help with the problem.
I hope somebody can help, because I think we are very close to a fully
functional CAM here.
I ran out of things to test to get closer to the solution :(
Btw: Is there any documentation available for the mantis PCI bridge?
Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
