if_em problems, both 7 and 8-stable

Pete Carah pete at altadena.net
Mon Jun 21 22:06:03 UTC 2010


On 06/19/2010 08:26 PM, Brandon Gooch wrote:
> On Sat, Jun 19, 2010 at 5:28 PM, Pete Carah <pete at altadena.net> wrote:
>   
>> I cannot successfully create a vlan on if_em on either releng 7 or releng 8;
>> I have seen a patch for part of
>> the problem (checksum offsets end up incorrect) but not all.  Even turning
>> off ALL hw_xxx flags leaves one
>> unacceptable bug - the interface gets hard-reset any time you add or delete
>> a vlan.  I *know* that cisco
>> uses these interfaces without these problems, so it has to be possible.  I
>> have used vlans in linux without
>> appearing to get the same problems, though I'm not sure the rest of the
>> configuration matches.
>>
>> What gives, especially since the patch for one of the problems (wrong
>> checksum offsets) was generated
>> about 6 months ago...
>>
>> We are trying to use an intel platform as a router; this is a show-stopper.
>>  I could try linux though I prefer not to...
>>     
> Would it be possible for you to provide more details about the
> hardware and software setup? The Intel chip and the revision (or
> relevant CVS info) about the builds of 7-RELENG and 8-RELENG would be
> useful, perhaps the dmesg of the machine and output of `pciconf -lv`?
>
> For what it's worth, I'm using vlans on an "Intel 82566DM Gigabit
> Ethernet Adapter (82566DM)", on-board in my Dell Optiplex 755, all
> hardware options on...
>   
825{5,6,7,8,9}x and 8254x (ours are 82546EB) are totally different
animals.  The bug we see
is definitely there for 54x; we are not the only ones seeing it - look
back in the stable
and net mailing-list archives for last December, a patch was sent in
back then and never
applied to the main tree, even -current.  See PR's
kern-141285
kern-141843
kern-146358 (likely related since it seems the same as 141843)
and perhaps a couple more.  All of those are still open and marked as
not yet
patched as of a half-hour ago.

Also, the patch (for 141285; the author thinks it fixes 141843 also) as
sent fixes some of
the offload problems but not all.

The problem with the interface resetting on vlan creation is there for
*all* if_em devices
and is independent of enabling hardware offloads; it causes a one or two
second pause in
forwarding (longer if you are connected to a Cisco without portfast, and
their newer
switches don't allow portfast on trunk ports); doesn't appear too
serious until you realize
how many packets per second one of these guys forwards in router service
- this is a LOT of
dropped packets.  My reading of the reset code is such that once vlan
service is enabled then
there might well be problems on untagged packets sent out that same
interface (not a problem
in our network but we don't have any 3com switches which REQUIRE
untagged management)

I have successful vlan networks running on sis, fxp, and vr interfaces
with absolutely no
problems (well, vr in fbsd 6 required a patch to up the receive buffer
size, but 7 and later
is fine with all of these out of the box.)

-- Pete

> $ ifconfig em0
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
>         ether 00:1e:4f:d5:84:b7
>         inet 10.7.0.7 netmask 0xff000000 broadcast 10.255.255.255
>         media: Ethernet autoselect (1000baseT <full-duplex>)
>         status: active
>
> -Brandon
>
>   



More information about the freebsd-stable mailing list