Bug #224

lnc(4) driver ported from freebsd (le(4))

Added by bill.marquette over 8 years ago. Updated over 8 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I was interested in learning something about the kernel, so figured
I'd take a crack at porting the le(4) driver that FreeBSD brought in
from NetBSD - the ultimate goal is to bring pcn(4) from NetBSD over -
the combination of the two drivers appears to be better than the
existing lnc(4)/pcn(4) that Dragonfly has today (at least for VMWare)
and supports VLANs which the existing lnc(4) doesn't appear to (maybe
I missed something). As Dragonfly already has a le(4) driver and this
was really a replacement for the existing lnc(4), I changed the driver
name to lnc (functions and some defines are a little goofy right now
because of it - looking for a little direction there).

If there's interest, I'm looking for a little feedback on the port. I
know there's still some cleanup to do (and a man page update!), but
more importantly:

I borrowed the lock code from aac(4) - I'm not sure it's the "right
way" to do things as it's the only driver that seems to use lock(9)
functions - but it was the easiest one to use to see Dragonfly vs
FreeBSD differences.
I ifdef'd out FreeBSD-isms (I still have some cleaning to do there) -
I'm not sure how that's treat in the Dragonfly tree, I only see a few
instances of that in the network drivers, maybe that code should just
go?
FreeBSD has BUS_PROBE_LOW_PRIORITY to set bus priorities so drivers
can pre-empt other drivers, I didn't see anything akin to that in
Dragonfly (and sadly hardcoded the value - this needs to be cleaned up
still). The old driver defined LNC_PROBE_PRIORITY to -1, is that the
"correct way" ? :)

With all that said...it does work :) I've been running it for a
couple days now in vmware without any issues (file transfers, multiple
simultaneous ifconfig up/down).

The patch can be found at: http://www.pfsense.org/~billm/dfly/lnc.patch

The patch removes if_lnc.c and if_lnc.h
and adds lance.c am7990.c am79900.c

I just noticed that I'm not rm'ing if_lncvar.h and if_lncreg.h - doh!

Original dmesg snippet in vmware
lnc0: <PCNet/PCI Ethernet adapter> port 0x1400-0x147f irq 11 at device
17.0 on pci0
lnc0: MAC address: 00:0c:29:d0:ad:ef
lnc0: PCnet-PCI

#ifconfig lnc0
lnc0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ether 00:0c:29:d0:ad:ef

new dmesg snippet in vmware
lnc0: <AMD PCnet-PCI> port 0x1400-0x147f irq 11 at device 17.0 on pci0
lnc0: 16 receive buffers, 4 transmit buffers
lnc0: MAC address: 00:0c:29:d0:ad:ef

#ifconfig lnc0
lnc0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
ether 00:0c:29:d0:ad:ef
media: Ethernet autoselect

--Bill

History

#1 Updated by sepherosa over 8 years ago

On 7/2/06, Bill Marquette <> wrote:
> I was interested in learning something about the kernel, so figured
> I'd take a crack at porting the le(4) driver that FreeBSD brought in
> from NetBSD - the ultimate goal is to bring pcn(4) from NetBSD over -
> the combination of the two drivers appears to be better than the
> existing lnc(4)/pcn(4) that Dragonfly has today (at least for VMWare)

VMware only uses lnc(4)

> and supports VLANs which the existing lnc(4) doesn't appear to (maybe
> I missed something). As Dragonfly already has a le(4) driver and this
> was really a replacement for the existing lnc(4), I changed the driver
> name to lnc (functions and some defines are a little goofy right now
> because of it - looking for a little direction there).
>
> If there's interest, I'm looking for a little feedback on the port. I
> know there's still some cleanup to do (and a man page update!), but
> more importantly:
>
> I borrowed the lock code from aac(4) - I'm not sure it's the "right
> way" to do things as it's the only driver that seems to use lock(9)
> functions - but it was the easiest one to use to see Dragonfly vs
> FreeBSD differences.
> I ifdef'd out FreeBSD-isms (I still have some cleaning to do there) -
> I'm not sure how that's treat in the Dragonfly tree, I only see a few
> instances of that in the network drivers, maybe that code should just
> go?

No extra lock is needed, all of the functions in "ifnet" struct are
called with ifp->if_serializer held, that means most functions in
network driver are protected by ifp->if_serializer (which you have
passed to bus_setup_intr() too). So you can safely nuke most of the
LE_(UN)LOCK stuffs, except for "suspend", "resume", "shutdown" and
"detach", LE_(UN)LOCK should be changed to
lwkt_serializer_{enter,exit}() there (you can take a look to xl(4) for
example). Special care should be taken for "detach": you should held
serializer for driver functions (e.g. lance_stop()) and
bus_teardown_intr(), while serializer should be released before
calling ether_ifdetach(), you can take a look at pcn_detach() for
example. Since no callouts are used, there is nothing to worry about
the callout callback functions, otherwise the callback functions
should hold serializer too.

> FreeBSD has BUS_PROBE_LOW_PRIORITY to set bus priorities so drivers
> can pre-empt other drivers, I didn't see anything akin to that in
> Dragonfly (and sadly hardcoded the value - this needs to be cleaned up
> still). The old driver defined LNC_PROBE_PRIORITY to -1, is that the
> "correct way" ? :)

Less than 0 is OK.

Thank you for the submission!!
If you can change the LE_(UN)LOCK stuffs, we can call for testing and
bring it into base soon.

Cheers,
sephe

#2 Updated by geekgod over 8 years ago

Bill Marquette wrote:
> I was interested in learning something about the kernel, so figured
> I'd take a crack at porting the le(4) driver that FreeBSD brought in
> from NetBSD - the ultimate goal is to bring pcn(4) from NetBSD over -
> the combination of the two drivers appears to be better than the
> existing lnc(4)/pcn(4) that Dragonfly has today (at least for VMWare)
> and supports VLANs which the existing lnc(4) doesn't appear to (maybe
> I missed something). As Dragonfly already has a le(4) driver and this
> was really a replacement for the existing lnc(4), I changed the driver
> name to lnc (functions and some defines are a little goofy right now
> because of it - looking for a little direction there).
>
> If there's interest, I'm looking for a little feedback on the port. I
> know there's still some cleanup to do (and a man page update!), but
> more importantly:
>
> I borrowed the lock code from aac(4) - I'm not sure it's the "right
> way" to do things as it's the only driver that seems to use lock(9)
> functions - but it was the easiest one to use to see Dragonfly vs
> FreeBSD differences.
> I ifdef'd out FreeBSD-isms (I still have some cleaning to do there) -
> I'm not sure how that's treat in the Dragonfly tree, I only see a few
> instances of that in the network drivers, maybe that code should just
> go?
> FreeBSD has BUS_PROBE_LOW_PRIORITY to set bus priorities so drivers
> can pre-empt other drivers, I didn't see anything akin to that in
> Dragonfly (and sadly hardcoded the value - this needs to be cleaned up
> still). The old driver defined LNC_PROBE_PRIORITY to -1, is that the
> "correct way" ? :)
>
> With all that said...it does work :) I've been running it for a
> couple days now in vmware without any issues (file transfers, multiple
> simultaneous ifconfig up/down).
>
> The patch can be found at: http://www.pfsense.org/~billm/dfly/lnc.patch
>
> The patch removes if_lnc.c and if_lnc.h
> and adds lance.c am7990.c am79900.c
>
> I just noticed that I'm not rm'ing if_lncvar.h and if_lncreg.h - doh!
>
> Original dmesg snippet in vmware
> lnc0: <PCNet/PCI Ethernet adapter> port 0x1400-0x147f irq 11 at device
> 17.0 on pci0
> lnc0: MAC address: 00:0c:29:d0:ad:ef
> lnc0: PCnet-PCI
>
> #ifconfig lnc0
> lnc0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
> ether 00:0c:29:d0:ad:ef
>
> new dmesg snippet in vmware
> lnc0: <AMD PCnet-PCI> port 0x1400-0x147f irq 11 at device 17.0 on pci0
> lnc0: 16 receive buffers, 4 transmit buffers
> lnc0: MAC address: 00:0c:29:d0:ad:ef
>
> #ifconfig lnc0
> lnc0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
> options=8<VLAN_MTU>
> ether 00:0c:29:d0:ad:ef
> media: Ethernet autoselect
>
> --Bill

I have also ran this patch for a few days with no issues.

If there is no objections I would like to commit this by Thursday 7/1/2006.

Scott

#3 Updated by sepherosa over 8 years ago

On 7/2/06, Scott Ullrich <> wrote:
>
> I have also ran this patch for a few days with no issues.
>
> If there is no objections I would like to commit this by Thursday 7/1/2006.

Please hold this off. I think Bill may be interested to "correct the
LOCK" usage as I had pointed out. If he didn't have time, I would do
it. But before that, IMHO, we should not push it into base.

Best Regards,
sephe

#4 Updated by bill.marquette over 8 years ago

On 7/2/06, Sepherosa Ziehau <> wrote:
> On 7/2/06, Scott Ullrich <> wrote:
> >
> > I have also ran this patch for a few days with no issues.
> >
> > If there is no objections I would like to commit this by Thursday 7/1/2006.
>
> Please hold this off. I think Bill may be interested to "correct the
> LOCK" usage as I had pointed out. If he didn't have time, I would do
> it. But before that, IMHO, we should not push it into base.
>
> Best Regards,
> sephe

I agree, working on that now (and the man page...can't commit this
without documentation! ;) ) along with the other ifdef cleanups I
mentioned earlier. Thanks

--Bill

#5 Updated by bill.marquette over 8 years ago

On 7/2/06, Sepherosa Ziehau <> wrote:
> On 7/2/06, Bill Marquette <> wrote:
> > I was interested in learning something about the kernel, so figured
> > I'd take a crack at porting the le(4) driver that FreeBSD brought in
> > from NetBSD - the ultimate goal is to bring pcn(4) from NetBSD over -
> > the combination of the two drivers appears to be better than the
> > existing lnc(4)/pcn(4) that Dragonfly has today (at least for VMWare)
>
> VMware only uses lnc(4)
>
> > and supports VLANs which the existing lnc(4) doesn't appear to (maybe
> > I missed something). As Dragonfly already has a le(4) driver and this
> > was really a replacement for the existing lnc(4), I changed the driver
> > name to lnc (functions and some defines are a little goofy right now
> > because of it - looking for a little direction there).
> >
> > If there's interest, I'm looking for a little feedback on the port. I
> > know there's still some cleanup to do (and a man page update!), but
> > more importantly:
> >
> > I borrowed the lock code from aac(4) - I'm not sure it's the "right
> > way" to do things as it's the only driver that seems to use lock(9)
> > functions - but it was the easiest one to use to see Dragonfly vs
> > FreeBSD differences.
> > I ifdef'd out FreeBSD-isms (I still have some cleaning to do there) -
> > I'm not sure how that's treat in the Dragonfly tree, I only see a few
> > instances of that in the network drivers, maybe that code should just
> > go?
>
> No extra lock is needed, all of the functions in "ifnet" struct are
> called with ifp->if_serializer held, that means most functions in
> network driver are protected by ifp->if_serializer (which you have
> passed to bus_setup_intr() too). So you can safely nuke most of the
> LE_(UN)LOCK stuffs, except for "suspend", "resume", "shutdown" and
> "detach", LE_(UN)LOCK should be changed to
> lwkt_serializer_{enter,exit}() there (you can take a look to xl(4) for
> example). Special care should be taken for "detach": you should held
> serializer for driver functions (e.g. lance_stop()) and
> bus_teardown_intr(), while serializer should be released before
> calling ether_ifdetach(), you can take a look at pcn_detach() for
> example. Since no callouts are used, there is nothing to worry about
> the callout callback functions, otherwise the callback functions
> should hold serializer too.
>
> > FreeBSD has BUS_PROBE_LOW_PRIORITY to set bus priorities so drivers
> > can pre-empt other drivers, I didn't see anything akin to that in
> > Dragonfly (and sadly hardcoded the value - this needs to be cleaned up
> > still). The old driver defined LNC_PROBE_PRIORITY to -1, is that the
> > "correct way" ? :)
>
> Less than 0 is OK.
>
>
> Thank you for the submission!!
> If you can change the LE_(UN)LOCK stuffs, we can call for testing and
> bring it into base soon.

OK, updated patch at http://www.pfsense.org/~billm/dfly/lnc.patch
it includes the LOCK -> serializer fixes, some crit_enter/exit fixes
that I think were needed, defining the bus probe priority (-100), and
removing FreeBSD specific code.

I've still got the man page to update, but I think/hope this is
correct enough to go in after the freeze for 1.6 is lifted.

--Bill

#6 Updated by sepherosa over 8 years ago

On 7/6/06, Bill Marquette <> wrote:
>
> OK, updated patch at http://www.pfsense.org/~billm/dfly/lnc.patch
> it includes the LOCK -> serializer fixes, some crit_enter/exit fixes
> that I think were needed, defining the bus probe priority (-100), and
> removing FreeBSD specific code.

Yeah, that's it!!
I have fixed some small nits in am7990.c, nuked ether_cmp(), and added
back the missing conf/files patch, please test:
http://leaf.dragonflybsd.org/~sephe/lnc.diff

If there is no problem, I'd like to commit it before 1.6 is slipped.

>
> I've still got the man page to update, but I think/hope this is

Sascha is waiting for it now :-)

Cheers,
sephe

#7 Updated by bill.marquette over 8 years ago

On 7/6/06, Sepherosa Ziehau <> wrote:
> > I've still got the man page to update, but I think/hope this is
>
> Sascha is waiting for it now :-)

And the patch for the man page is at:
http://www.pfsense.org/~billm/dfly/lnc.4.patch

--Bill

#8 Updated by sepherosa over 8 years ago

On 7/7/06, Bill Marquette <> wrote:
> On 7/6/06, Sepherosa Ziehau <> wrote:
> > > I've still got the man page to update, but I think/hope this is
> >
> > Sascha is waiting for it now :-)
>
> And the patch for the man page is at:
> http://www.pfsense.org/~billm/dfly/lnc.4.patch
>

Committed, thanks!!

Cheers,
sephe

#9 Updated by bill.marquette over 8 years ago

commited by sepherosa

Also available in: Atom PDF