WOW, I want to really thank you for finding this Patrick.
In Febuary 2006 Gleb introduced a drastic rename of our
adapter struct, it introduced a HUGE amount of diffs, we (Intel)
did not want that change and eventually it was backed out,
however it was in that delta that the bang got lost in this
Hmmm, this looks like a bug, I will look more closely today.
Sorry I have not been able to be more active with your problem,
but things have been hectic with product launches and my own
internal bug fixing. I will try to get this turned around quickly
Patrick.
Jack
On 7/24/07, Patrick Oeschger
OK - found the problem
the driver in 6.2-RELEASE has different code in em_identify_hardware
my hardware needs the memory access and bus master bits getting set by
the driver
beginning with 6.2-RELEASE this gets only set if PCIM_CMD_BUSMASTEREN is
*not set* and PCIM_CMD_MEMEN is *set* - it seems the
thanks for your feedback jack - i tried the MSI stuff as first task this
morning
the interface init'ed without a problem and did not complain about MSI
what i like most is that no IRQ is assigned now, everything seems to get
handled in a TASKQ (IRQs were quite weird sometimes when having a bunch of
As an experiment, search in if_em.c for 'msix' look at the logic there.
If the adapter is 82575 it will use msix, but the else clause has it
use msi ONLY if its '>82571', change that to >=82571 and let's
see if maybe using MSI will help you with your problems as I'm
pretty confident its interrupt
bug description for 7.0-CURRENT - em(4) driver version 6.5.3
- frame reception is not possible (missed packets counter incrementing)
- frame transmission is not possible (driver watchdog fires)
bug exists also on 6.2-RELENG - em(4) driver version 6.2.9
bug does *not* exist on 6.1-RELENG - em(4) dri
