On Tue, May 31, 2011 at 12:52:15PM +0800, Sepherosa Ziehau wrote:
>
> You probably need to change dev/netif/igb instead of em and ig_hal.
> You could simply add the PCI ids to igb and see whether it works or
> not.
>
The plot thickens -
based on a whole lot of suppositions, b/c it would take hours
to review the history and someone here probably knows it better
anyhow -
It looks something like em driver (perhaps btw v6-7 of the intel rev?)
grew into the e1000 driver, with pcie support - and a 'legacy' em(4)
driver - subsequent updates? were made to the e1000/*em* items,
such as adding more chips -
Our e1000/em contains what apppears to be the needed items for this card:
em0@pci0:0:25:0: class=0x020000 card=0x80001025 chip=0x10f08086
rev=0x06 hdr=0x00
e1000_api.c: case E1000_DEV_ID_PCH_D_HV_DC:
e1000_hw.h:#define E1000_DEV_ID_PCH_D_HV_DC 0x10F0
if_em.c: { 0x8086, E1000_DEV_ID_PCH_D_HV_DC, PCI_ANY_ID, PCI_ANY_ID,
0},
(the 0x10F0 being the relavent bits)
which are not in the 'live' sys/dev/netif/em driver -
however, this copy of 'em' (sys/dev/netif/e1000/em) is not linked
into the build - whereas the sys/dev/netif/em copy is.
I was able to :
cd sys/dev/netif/e1000/em && wmake
to get a clean 'if_em.ko' - no idea if this will probe/attach/send packets
and so on..
So - Siju - feel free to build that and test I suppose -
not sure where to take it from here w/r/t 'em' development - either
to disable / merge in the relavent bits of sys/dev/netif/em to e1000/em,
or the other way around, etc..
my thoughts would be to use the new copy - however it does appear
that someone at some point took the time to cleanly separate the phy
stuff, into that 'ig_hal' etc- so maybe this was overlooked when e1000
was added, I dunno.. (see history, above :D )
so - I will defer to the experts
cheers
- Chris
