Re: Intel Corporation 82578DC Gigabit NIC support

2011-07-12 Thread Siju George
Hi Sepherosa,

Sorry for the late response. I was sick and could not get the new desktop.
I grabbed today's snapshot and it works like a charm :-D

Thanks a million

--Siju

On Tue, Jun 28, 2011 at 11:27 AM, Sepherosa Ziehau sepher...@gmail.comwrote:

 On Fri, Mar 4, 2011 at 12:47 PM, Siju George sgeorge...@gmail.com wrote:
  Hi,
 
  My new Desktop's EtherNet Card is
 
  Intel Corporation 82578DC Gigabit NIC (rev 06)
 
  OpenBSD detects it as em0 but dragonfly does not detect it :-(
  Is there any thing I need to do like kernel configurations etc?
  Or should I wait till the driver is ported?

 Please test the latest master:
 2d0e5700f20de35b08afb96e1871776a16447d99

 It should be working.

 Best Regards,
 sephe

 --
 Tomorrow Will Never Die



Re: Intel Corporation 82578DC Gigabit NIC support

2011-06-28 Thread Sepherosa Ziehau
On Fri, Mar 4, 2011 at 12:47 PM, Siju George sgeorge...@gmail.com wrote:
 Hi,

 My new Desktop's EtherNet Card is

 Intel Corporation 82578DC Gigabit NIC (rev 06)

 OpenBSD detects it as em0 but dragonfly does not detect it :-(
 Is there any thing I need to do like kernel configurations etc?
 Or should I wait till the driver is ported?

Please test the latest master:
2d0e5700f20de35b08afb96e1871776a16447d99

It should be working.

Best Regards,
sephe

-- 
Tomorrow Will Never Die


Re: Intel Corporation 82578DC Gigabit NIC support

2011-05-31 Thread Chris Turner
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=0x02 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







Re: Intel Corporation 82578DC Gigabit NIC support

2011-05-31 Thread Sepherosa Ziehau
On Wed, Jun 1, 2011 at 5:49 AM, Chris Turner
c.tur...@199technologies.com wrote:
 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=0x02 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

Heh, netif/ig_hal (it was actually e1000 hardware related code from
Intel) was added before I took a short break from dfly in 2009, while
netif/e1000 code was added later to support igb only.  Currently I
don't have enough time to put the whole thing into shape; the hardware
related bits will finally go into netif/ig_hal.  However, as I have
suggested, if you want 82578 to work, you probably need to change the
stuffs under netif/e1000/igb instead of netif/em or netif/emx.

Best Regards,
sephe

-- 
Tomorrow Will Never Die



Re: Intel Corporation 82578DC Gigabit NIC support

2011-05-30 Thread Siju George
On Fri, Mar 4, 2011 at 1:10 PM, Chris Turner
c.tur...@199technologies.org wrote:
 On 03/03/11 22:47, Siju George wrote:

 OpenBSD detects it as em0 but dragonfly does not detect it :-(
 Is there any thing I need to do like kernel configurations etc?
 Or should I wait till the driver is ported?

 knowing nothing about the driver itself -
 a quick check of our manual vs their manual
 and it does look like the same driver

 I'd suggest hacking pcidevs and seeing what happens when you build it..
 it might just work


Thaks for your reply :-)
Which files should I edit for this?

 (or not, depending)

 basically pciconf -lv will show the device hex stuff,
 and you can hack the general pcidevs file,
 and the driver stuff that matches it

 when that's all in place, the driver should try to attach,
 and either work, not work, or cause a panic :D

 after that well.. it's a matter of giving up or trying
 to see what the differences are

 of course if someone else has this hw working, this is all moot.


FreeBSD on the same machine has got this working.

em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0xdc00-0xdc1f
mem 0xfbbc-0xfbbd,0xfbbf6000-0xfbbf6fff irq 20 at device 25.0
on pci0
em0: Using an MSI interrupt
em0: [FILTER]

pciconf -lv on FreeBSD shows this output .

$ pciconf -lv
hostb0@pci0:0:0:0:  class=0x06 card=0x04011025 chip=0x00408086
rev=0x12 hdr=0x00
vendor = 'Intel Corporation'
class  = bridge
subclass   = HOST-PCI
vgapci0@pci0:0:2:0: class=0x03 card=0x04011025 chip=0x00428086
rev=0x12 hdr=0x00
vendor = 'Intel Corporation'
class  = display
subclass   = VGA
none0@pci0:0:22:0:  class=0x078000 card=0x04011025 chip=0x3b648086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = simple comms
atapci0@pci0:0:22:2:class=0x010185 card=0x04011025 chip=0x3b668086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = mass storage
subclass   = ATA
none1@pci0:0:22:3:  class=0x070002 card=0x04011025 chip=0x3b678086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = simple comms
subclass   = UART
em0@pci0:0:25:0:class=0x02 card=0x80001025 chip=0x10f08086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = network
subclass   = ethernet
ehci0@pci0:0:26:0:  class=0x0c0320 card=0x04011025 chip=0x3b3c8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = serial bus
subclass   = USB
none2@pci0:0:27:0:  class=0x040300 card=0x04011025 chip=0x3b568086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = multimedia
subclass   = HDA
ehci1@pci0:0:29:0:  class=0x0c0320 card=0x04011025 chip=0x3b348086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = serial bus
subclass   = USB
pcib1@pci0:0:30:0:  class=0x060401 card=0x04011025 chip=0x244e8086
rev=0xa6 hdr=0x01
vendor = 'Intel Corporation'
device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub
Interface to PCI Bridge'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 card=0x04011025 chip=0x3b088086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = bridge
subclass   = PCI-ISA
atapci1@pci0:0:31:2:class=0x01018f card=0x04011025 chip=0x3b208086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'IBEX SATA Controller'
class  = mass storage
subclass   = ATA
none3@pci0:0:31:3:  class=0x0c0500 card=0x04011025 chip=0x3b308086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
class  = serial bus
subclass   = SMBus
atapci2@pci0:0:31:5:class=0x010185 card=0x04011025 chip=0x3b268086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'IBEX SATA Controller'
class  = mass storage
subclass   = ATA


Re: Intel Corporation 82578DC Gigabit NIC support

2011-05-30 Thread Chris Turner
Hello -

On Mon, May 30, 2011 at 12:10:10PM +0530, Siju George wrote:
 
 Thaks for your reply :-)
 Which files should I edit for this?


I took a look at this w/r/t the FreeBSD / openbsd drivers to try and
provide some hints, and it looks like this is a 'non trivial' case -
that is to say, there is various device-specific code for the driver
which looks to be required to make this particular chip work.

Sorry to get the hopes up!

(removes foot from mouth)

That being said, it also doesn't seem like there is *too much* 
chip specific stuff, so it probably would not be too much of a port.

As I gave bad advice previously, I will take a crack at this tomorrow.

FYI - related files are:

  sys/dev/e1000 in the freebsd tree

and

  sys/dev/netif/em
  sys/dev/netif/ig_hal

along with:

  sys/bus/pci/pcidevs

in ours.

grepping around for 82578 shows what appears to be all the related 
missing pieces.

Cheers,

- Chris



Re: Intel Corporation 82578DC Gigabit NIC support

2011-05-30 Thread Sepherosa Ziehau
On Tue, May 31, 2011 at 5:27 AM, Chris Turner
c.tur...@199technologies.com wrote:
 Hello -

 On Mon, May 30, 2011 at 12:10:10PM +0530, Siju George wrote:

 Thaks for your reply :-)
 Which files should I edit for this?


 I took a look at this w/r/t the FreeBSD / openbsd drivers to try and
 provide some hints, and it looks like this is a 'non trivial' case -
 that is to say, there is various device-specific code for the driver
 which looks to be required to make this particular chip work.

 Sorry to get the hopes up!

 (removes foot from mouth)

 That being said, it also doesn't seem like there is *too much*
 chip specific stuff, so it probably would not be too much of a port.

 As I gave bad advice previously, I will take a crack at this tomorrow.

 FYI - related files are:

  sys/dev/e1000 in the freebsd tree

 and

  sys/dev/netif/em
  sys/dev/netif/ig_hal

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.

Best Regards,
sephe

-- 
Tomorrow Will Never Die



Re: Intel Corporation 82578DC Gigabit NIC support

2011-03-03 Thread Chris Turner

On 03/03/11 22:47, Siju George wrote:

OpenBSD detects it as em0 but dragonfly does not detect it :-(
Is there any thing I need to do like kernel configurations etc?
Or should I wait till the driver is ported?


knowing nothing about the driver itself -
a quick check of our manual vs their manual
and it does look like the same driver

I'd suggest hacking pcidevs and seeing what happens when you build it..
it might just work

(or not, depending)

basically pciconf -lv will show the device hex stuff,
and you can hack the general pcidevs file,
and the driver stuff that matches it

when that's all in place, the driver should try to attach,
and either work, not work, or cause a panic :D

after that well.. it's a matter of giving up or trying
to see what the differences are

of course if someone else has this hw working, this is all moot.

cheers