When comparing there (in HEAD) I found many changes, most of them are not related with my hardware. Would it compile on FreeBSD 8.1-RELEASE-p1 ? I could try on secondary router and test it again with 1Gbs traffic.
Regards, Rolandas Naujikas On 2010.11.21, at 00:13, Jack Vogel wrote: > 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.nauji...@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.nauji...@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, rol...@gmail.com wrote: >>>>>> >>>>>>> On 2010.11.20, at 17:54, Jeremy Chadwick wrote: >>>>>>> >>>>>>>> On Sat, Nov 20, 2010 at 05:09:28PM +0200, rol...@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 >>>>>>> >>>>>>> e...@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 r...@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 j...@parodius.com | >>>>> | Parodius Networking http://www.parodius.com/ | >>>>> | UNIX Systems Administrator Mountain View, CA, USA | >>>>> | Making life hard for others since 1977. PGP: 4BD6C0CB | >>>>> >>>> >>>> >> >> _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
