problems with network on em

Jack Vogel jfvogel at gmail.com
Sat Nov 20 22:13:34 UTC 2010 

I'd appreciate it if you could try and get the driver from HEAD, I will be
putting it into STABLE
next week, and it would be nice to see if it fixed your problem. It will
build in your STABLE
environment just fine, do you know how to do this, if not just say so and I
can give you
further details.

Regards,

Jack


On Sat, Nov 20, 2010 at 1:53 PM, Naujikas Rolandas <
Rolandas.Naujikas at mif.vu.lt> wrote:

> I don't know about version, but I'm using RELENG_8 branch only. It is
> FreeBSD 8-STABLE also.
>
> Regards, Rolandas Naujikas
>
> P.S. I just got ~1Gbit/s (125MB/s,115Kpps) forwarding traffic in testing
> (24 nodes was downloading a file with wget from server from another side of
> router), but finally there was some deadlock. I'm recovering the data on it.
>
> On 2010.11.20, at 22:37, Jack Vogel wrote:
>
> > Did you mean the 7.1.7 version from HEAD ?
> >
> > Jack
> >
> >
> > On Sat, Nov 20, 2010 at 11:18 AM, Naujikas Rolandas <
> > Rolandas.Naujikas at mif.vu.lt> wrote:
> >
> >> I'm trying to test with newest version of /sys/dev/e1000 from FreeBSD
> >> 8-STABLE.
> >> For that I'm using loadable module option, because it is easier to build
> >> with minimal changes in kernel source.
> >> Only /sys/dev/e1000 and /sys/modules/em need to be updated.
> >> Without changes in /sys/modules/em/Makefile it compiles, but have
> missing
> >> symbol or if you compile static kernel - the same problem.
> >> Now I'm testing and it looks promising (except I see a little bigger
> kernel
> >> thread netisr cpu load, but it's acceptable).
> >>
> >> Regards, Rolandas Naujikas
> >>
> >> On 2010.11.20, at 19:05, Jeremy Chadwick wrote:
> >>
> >>> On Sat, Nov 20, 2010 at 06:38:19PM +0200, Naujikas Rolandas wrote:
> >>>> I just got another lockup.
> >>>> It looks like in the time of lockup the number of Ierrs is increasing:
> >>>> Name    Mtu Network       Address              Ipkts Ierrs Idrop
> >> Opkts Oerrs  Coll
> >>>> em2    1500 <Link#3>      00:14:4f:XX:XX:XX 13060395 18438     0
> >> 6579984     1     0
> >>>>
> >>>> After "ifconfig em2 down;ifconfig em2 up" Ierrs stays at 0 rate for
> long
> >> time.
> >>>> Without DEVICE_POLLING it was similar situation.
> >>>>
> >>>> Regards, Rolandas Naujikas
> >>>>
> >>>> On 2010.11.20, at 18:24, rolnas at gmail.com wrote:
> >>>>
> >>>>> On 2010.11.20, at 17:54, Jeremy Chadwick wrote:
> >>>>>
> >>>>>> On Sat, Nov 20, 2010 at 05:09:28PM +0200, rolnas at gmail.com wrote:
> >>>>>>> I'm experiencing network interface stalls on em in FreeBSD
> >> 8.1-RELEASE (-p1).
> >>>>>>> It looks like the problem could be solved in 8-STABLE, but should I
> >> upgrade to it ?
> >>>>>>> Is it OK to try to get only em driver code and recompile as module
> >> and try to run it ?
> >>>>>>>
> >>>>>>> sysctl dev.em.2.stats=1:
> >>>>>>> ...
> >>>>>>> em2: Missed Packets = 101334
> >>>>>>> em2: Receive No Buffers = 488
> >>>>>>> ...
> >>>>>>> em2: RX overruns = 1356
> >>>>>>> em2: watchdog timeouts = 1
> >>>>>>> ...
> >>>>>>>
> >>>>>>> Only "ifconfig em2 down;ifconfig em2 up" helps for some time.
> >>>>>>> The same happens on em0 interface only, but not in the same time.
> >>>>>>> It is production (NAT) router with pf+pfsync+carp and failover over
> >> another router.
> >>>>>>> They are old "SunFire X4100" boxes (4GB RAM, 2*2 AMD Opteron
> 2.2GHz).
> >>>>>>
> >>>>>> You're going to need to provide output from the following, run as
> >> root.
> >>>>>> For the pciconf command, please only include the entry that's
> relevant
> >>>>>> to the device in question (em2).  You can also XXX-out the MAC
> address
> >>>>>> and/or IP addresses if you're worried about security.
> >>>>>>
> >>>>>> $ pciconf -lvc
> >>>>>
> >>>>> em2 at pci0:1:2:0: class=0x020000 card=0x10118086 chip=0x10108086
> >> rev=0x03 hdr=0x00
> >>>>>  vendor     = 'Intel Corporation'
> >>>>>  device     = 'Dual Port Gigabit Ethernet Controller (Copper)
> >> (82546EB)'
> >>>>>  class      = network
> >>>>>  subclass   = ethernet
> >>>>>  cap 01[dc] = powerspec 2  supports D0 D3  current D0
> >>>>>  cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split
> >> transaction
> >>>>>  cap 05[f0] = MSI supports 1 message, 64 bit
> >>>>>
> >>>>>> $ dmesg | grep em2
> >>>>>
> >>>>> em2: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port
> >> 0x9400-0x943f mem 0xfbfa0000-0xfbfbffff irq 24 at device 2.0 on pci1
> >>>>> em2: [FILTER]
> >>>>> em2: Ethernet address: 00:14:4f:XX:XX:XX
> >>>>>
> >>>>>> $ sysctl dev.em.2
> >>>>>
> >>>>> dev.em.2.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.1
> >>>>> dev.em.2.%driver: em
> >>>>> dev.em.2.%location: slot=2 function=0
> >>>>> dev.em.2.%pnpinfo: vendor=0x8086 device=0x1010 subvendor=0x8086
> >> subdevice=0x1011 class=0x020000
> >>>>> dev.em.2.%parent: pci1
> >>>>> dev.em.2.debug: -1
> >>>>> dev.em.2.stats: -1
> >>>>> dev.em.2.rx_int_delay: 0
> >>>>> dev.em.2.tx_int_delay: 66
> >>>>> dev.em.2.rx_abs_int_delay: 66
> >>>>> dev.em.2.tx_abs_int_delay: 66
> >>>>> dev.em.2.rx_processing_limit: 100
> >>>>>
> >>>>>> $ uname -a
> >>>>>
> >>>>> FreeBSD sunfire1.mif 8.1-RELEASE-p1 FreeBSD 8.1-RELEASE-p1 #2: Thu
> Nov
> >> 18 10:39:07 EET 2010     root at sunfire1.mif
> :/home/local/obj/usr/src/sys/SUNFIRE
> >> amd64
> >>>>>
> >>>>> Recompiled with DEVICE_POLLING and HZ=2000, carp and many not used
> >> devices removed.
> >>>>>
> >>>>>> $ netstat -ind -I em2
> >>>>>
> >>>>> Name    Mtu Network       Address              Ipkts Ierrs Idrop
> >> Opkts Oerrs  Coll Drop
> >>>>> em2    1500 <Link#3>      00:14:4f:XX:XX:XX 66430440 101334     0
> >> 59339619     1     0    0
> >>>>> em2    1500 192.168.0.0/1 192.168.XX.XXX      633845     -     -
> >> 3815946     -     -    -
> >>>>> ...
> >>>>> em0    1500 <Link#1>      00:14:4f:XX:XX:XX 167143400 152726     0
> >> 143900328     0     0    0
> >>>>>
> >>>>> Regards, Rolandas Naujikas
> >>>>>
> >>>>>> Thanks.
> >>>
> >>> Oops, I forgot requesting output from one other command:
> >>>
> >>> $ vmstat -i
> >>>
> >>> Adding Jack Vogel to the thread, who might have ideas/comments.  Jack,
> >>> here's the thread:
> >>>
> >>>
> >>
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060183.html
> >>>
> >>> As for my comments:
> >>>
> >>> Unidirectional errors (input or output) often indicates a duplex
> >>> mismatch or some sort of weird "quirk" between one link partner and the
> >>> other.  I *have* seen cases where both sides are auto-neg and one side
> >>> acts like it has the wrong duplex selection despite ifconfig reporting
> >>> full-duplex and the switch reporting full.  Forcing speed and duplex on
> >>> both ends (requires a managed switch; please don't try this with a
> >>> generic consumer switch) resolved the problem.
> >>>
> >>> It could be that there's a driver bug causing this to happen -- down/up
> >>> seems to indicate that could be the case -- but every situation needs
> to
> >>> be addressed individually.
> >>>
> >>> --
> >>> | Jeremy Chadwick                                   jdc at parodius.com |
> >>> | Parodius Networking                       http://www.parodius.com/ |
> >>> | UNIX Systems Administrator                  Mountain View, CA, USA |
> >>> | Making life hard for others since 1977.              PGP: 4BD6C0CB |
> >>>
> >>
> >>
>
>

More information about the freebsd-stable mailing list