On 22/11/12 15:42, Joel Sing wrote:
On Thu, 22 Nov 2012, Kapetanakis Giannis wrote:
Doing Per-Olov's advice on
http://marc.info/?l=openbsd-misc&m=133771632704741&w=2
and applying the following, fixes the problem.
Should I stick with this or is there another reason it has not been
included in current so far?
Yes - it is a work around for broken/incomplete emulation or incorrect
interrupt routing. Always doing this would result in a performance hit on all
systems. As shown in your dmesg, both em(4) devices are using the same IRQ:
em0 at pci0 dev 3 function 0 "Intel PRO/1000MT (82540EM)" rev 0x03: irq 11,
address 52:54:00:25:e7:a8
em1 at pci0 dev 4 function 0 "Intel PRO/1000MT (82540EM)" rev 0x03: irq 11,
address 52:54:00:8a:63:d6
With intr_shared_edge=0, we stop processing the interrupt chain once a device
reports that it had work to do. If there are other devices that need to be
serviced we expect the interrupt pin to still be asserted and a second
interrupt to trigger. With intr_shared_edge=1 we always process the entire
interrupt chain. In your case either the interrupt pin is not being asserted
correctly or the first device is always reporting that it had work to do,
even when it did not.
Do you see any difference if you use OpenBSD/amd64 instead? The interrupt
handling will be the same, but you may get more useful interrupt allocation.
Thanks for the reply Joel,
I didn't have the chance to test amd64 arch.
The funny thing is that right now even with the current kernel (without
the minor modification)
I'm not able to reproduce, which is a good thing but might turn bad in
the future.
If I have the issue again in the future I will use that workaround.
G
