Re: Intel 82574L Gigabit Ethernet Controller
On Mon, 2010-07-05 at 22:02 -0700, Jack Vogel wrote: > Cleaner in the Makefile, let me know how it goes. > > Jack > > > On Mon, Jul 5, 2010 at 12:06 PM, Yuriy A. Korobko > wrote: > > > On Mon, 2010-07-05 at 11:11 -0700, Jack Vogel wrote: > > > Are you defining 'EM_MULTIQUEUE', its off by default and needs to be > > > defined somewhere by you. > > > > > > You will only see the two queues used if you have two different > > connections > > > operating at once. > > > > > > Jack Recompiled module (actually whole kernel) with EM_MULTIQUEUE, but got a some watchdog timeouts. Here is example of netstat when it happens: 2346 0 0 583370 2642 02988379 0 2250 0 0 550961 2384 02835276 0 2634 0 0 703410 2733 02971417 0 2741 0 0 695884 2748 03061573 0 2811 0 0 618520 2274 03273868 0 3220 0 0 687145 2068 03417857 0 901 0 0 231694166 01565839 0 752 0 0 216135 0 0 270247 0 685 0 0 208745 0 0 243442 0 713 0 0 178089 0 0 230472 0 735 0 0 159555 0 0 178435 0 616 0 0 145222 0 0 179022 0 input (em1) output packets errs idrops bytespackets errs bytes colls 616 0 0 129608 0 0 120929 0 659 0 0 113806 0 0 105707 0 622 0 0 106247 0 0 107825 0 645 0 0 101593 0 0 38023 0 483 0 0 61681 0 0 8547 0 Watchdog timeout on em1 message on console 0 0 0 0 0 1 19095 0 0 0 0 0 0 0222 0 0 0 0 0 0 0 0 0 243 0 0 30224 1783 01708875 0 576 0 0 62350105 0 7710 0 467 0 0 49758 4 0 4388 0 500 0 0 53415 23 0 24743 0 437 0 0 50135 21 0 16733 0 After this traffic increased again up to 3 kpps and another watchdog timeout happened. em0: flags=8843 metric 0 mtu 1500 options=2098 ether 00:30:48:bc:ab:ca inet x.x.x.x netmask 0xffe0 broadcast x.x.x.y media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=2098 ether 00:30:48:bc:ab:cb media: Ethernet autoselect (1000baseT ) status: active em1 have 30 vlans and mpd5 as pppoe server listening on each vlan. Here is sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x02 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.rx_int_delay: 200 dev.em.0.tx_int_delay: 200 dev.em.0.rx_abs_int_delay: 500 dev.em.0.tx_abs_int_delay: 500 dev.em.0.rx_processing_limit: 100 dev.em.0.link_irq: 2 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.rx_overruns: 0 dev.em.0.mac_stats.watchdog_timeouts: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 732916 dev.em.0.mac_stats.good_pkts_recvd: 732916 dev.em.0.mac_stats.bcast_pkts_recvd: 1238 dev.em.0.mac_stats.mcast_pkts_recvd: 0 dev.em.0.mac_stats.rx_frames_64: 84622 dev.em.0.mac_stats.rx_frames_65_127: 128831 dev.em.0.mac_stats.rx_frames_128_255: 34037 dev.em.0.mac_stats.rx_frames_256_511: 30206 dev.em.0.mac_stats.rx_frames_512_1023: 24919 dev.em.0.mac_stats.rx_frames_1024_1522: 430301 dev.em.0.mac_stats.good_octets_recvd: 0 dev.em.0.mac_stats.good_octest_txd: 0 dev.em.0.mac_stats.total_pkts_txd: 678078 dev.em.0.mac_stats.good_pkts_txd: 678078 dev.em.0.mac_stats.bcast_pkts_txd: 109 dev.em.0.mac_stats.mcast_pkts_txd: 0 dev.em.0.mac_stats.tx_frames_64: 324803 dev.em.0.mac_stats.tx_frames_65_127: 196866 dev.em.0.mac_stats.tx_frames_128_255: 47362 dev.em.0.mac_stats.tx_frames_256_511: 31917 dev.em.0.mac_stats.tx_frames_512_1023: 44997 dev.em.0.
tuning igb 82257 in FreeBSD 8.0
Hello. The server is L2 bridge. uname -a: FreeBSD 8.0-STABLE-201005 FreeBSD 8.0-STABLE-201005 #1: Wed Jun 23 12:29:30 UTC 2010 /usr/src/sys/amd64/compile/MYKERNEL amd64 The network adapter is: Intel Gigabit ET Quad Port Server Adapter (Ethernet controller Intel 82257). Default drivers version in FreeBSD 8.0-STABLE-201005 is Intel(R) PRO/1000 Network Connection version - 1.9.5. We try to set up options below in /boot/loader.conf: if_igb_load="YES" hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.num_queues=0 hw.igb.enable_aim=1 hw.igb.low_latency=1000 hw.igb.ave_latency=2000 hw.igb.bulk_latency=4000 hw.igb.rx_process_limit=100 hw.igb.fc_setting=0 hw.igb.lro=0 The system boots successfully with drivers 1.9.5. But there are no specified earlier options in sysctl -a | grep igb.0, for example. sysctl -a|grep igb.0: dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.9.5 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10e8 subvendor=0x8086 subdevice=0xa02b class=0x02 dev.igb.0.%parent: pci3 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.rx_processing_limit: 100 We try to change drivers version to 1.8.4 from official site. The system boots successfully too and I can see this options in sysctl -a | grep igb.0. But there was some problem: I can explore only some sites through internet browser, for exmaple yandex.ru. Most of the sites I can`t see through the internet browser. But I can "ping" these sites by DNS name, I get DNS query successfully and I can see by tcpdump server replies. Next we have changed the drivers version to 1.7.4. But wih these options the system does not boot. There was an error: GET BUF: dmamap load failure - 12 I try to change hw.igb.rxd and hw.igb.txd in /boot/loader.conf like: 1.hw.igb.rxd=2048 hw.igb.txd=4096; 2.hw.igb.rxd=1024 hw.igb.txd=1024 - the same error. Also the same error with drivers version 1.7.3. But!!! We have another server: L2 bridge too with the same network adapter. uname -a: FreeBSD 7.2-STABLE-200906 FreeBSD 7.2-STABLE-200906 #1: Tue Oct 6 10:26:41 MSD 2009 /usr/src/sys/amd64/compile/MYKERNEL amd64 And we have no such problems like in bridge FreeBSD 8.0. Can anyone help me? Maybe I shouldn`t initialize such options in /loader.conf? Maybe in somewhere else? Thanks fo reply. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/145462: [netgraph] [patch] panic kernel when ng_ipfw send ip package on not existing netgraph node
Synopsis: [netgraph] [patch] panic kernel when ng_ipfw send ip package on not existing netgraph node State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Tue Jul 6 10:35:17 UTC 2010 State-Changed-Why: Fixed in head/. Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Tue Jul 6 10:35:17 UTC 2010 Responsible-Changed-Why: Fixed in head/. http://www.freebsd.org/cgi/query-pr.cgi?pr=145462 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic: rtqkill route really not free on freebsd 8.0-release update
Thank you Xin. Let me have a look and see if there is an alternative. -- Qing On Fri, Jul 2, 2010 at 2:26 PM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, Bjoern, > > On 2010/07/02 01:39, Bjoern A. Zeeb wrote: >> On Sat, 5 Jun 2010, Chao Shin wrote: >> >> Hey, >> >>> We add kdb/ddb and extra panic info printing into kernel and catch >>> this panic again. >>> >>> We have instrumented the kernel and found that this panic happens when >>> draining == 1, >>> but seems to be confused with the fact that all access to radix trees >>> are protected >>> by locks. Can anyone familiar with these code shed us some light on >>> this? >>> >>> below is url to screenshot in ddb: >>> http://www.delphij.net/zhao/1.png >>> http://www.delphij.net/zhao/2.png >> >> Did anyone pick this up? > > I don't think so. > > Currently we believe that there is some call paths that would exhibit > the following: > > Thread A Thread B > (...) > RTLOCK(rt) > rt->ref--; > [ref drops to 0 now] > (obtain rnh_lock) > (in in_matroute) > saw rt->ref == 0 > rt->rt_flags & RTPRF_OURS == 0 > (return from in_matroute()) > RT_LOCK(rt) <-- blocks here > rt->rt_flags |= OURS > RT_UNLOCK(rt); > RT_LOCK(rt) <-- got a wakeup > rt->ref++ > (ref == 1 && rt->rt_flags & RTPRF_OURS) > > With the attached workaround they have not see this type of panics so > far but that doesn't seem ideal. > > Kip and Qing's paper titled "Optimizing the BSD routing system for > parallel processing" suggests copying the route entry rather than > referencing it but I didn't yet on how should I implement that and do > benchmark... > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.15 (FreeBSD) > > iQEcBAEBCAAGBQJMLlmNAAoJEATO+BI/yjfBzvAIANjmEXX54lryJ6Qq37yUFdmd > BQqw7r/Q7IYD6gOBU0/iMUySa4x6H3U+8TPUK8Rf+ARkG8CP3JsRMPJtLkFs5Eby > lmvQDRcfcKzFCAC40m/FmdlCl0c2Q/mz5H4PYve3zuU+BEDN0NOEIUtnYVmOJK1U > 4O5XXZcAzNT1BXKKwbogwQq0t4dhT/3+4inH6vC3w8HpzwDfXS2GogFSOYlSurvC > h7b2wjrD7sgTPZZj1DN7qWjGSRNAao+AGzlzvQR6tNCqWV+bn8qF+QaNoFepev+g > ITeUh9IXffn646WCRF5whKUjz+M9IvSPhqGiFyWfhcGj8DbDt074XMsHiBLh7nc= > =lHSK > -END PGP SIGNATURE- > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: i386/45773: [bge] Softboot causes autoconf failure on Broadcom 5703
Synopsis: [bge] Softboot causes autoconf failure on Broadcom 5703 Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 19:45:32 UTC 2010 Responsible-Changed-Why: Take. There had been a lot of PHY related stuff changes and I guess it might be fixed. Would you try latest FreeBSD release(8.1-RC2 or 7.3-RELEASE) and let me know whether it's still issue or not? http://www.freebsd.org/cgi/query-pr.cgi?pr=45773 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/92090: [bge] bge0: watchdog timeout -- resetting
Synopsis: [bge] bge0: watchdog timeout -- resetting State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jul 6 20:08:31 UTC 2010 State-Changed-Why: If you are still seeing the issue on 8.1-RC2 or 7.3-RELEASE, please show me the verbosed dmesg output as well as "vmstat -i" and "ifconfig bge0". Floris, I think you're seeing ASF/IMPI issue on 9-CURRENT. Try disabling ASF functions by adding hw.bge.allow_asf="0" to /boot/loader.conf. Both 7.x and 8.x disabled it by default. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 20:08:31 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=92090 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable.
The following reply was made to PR kern/146517; it has been noted by GNATS. From: Vincent Hoffman To: bug-follo...@freebsd.org, vi...@unsane.co.uk Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Tue, 06 Jul 2010 21:23:50 +0100 Hi, I've updated to FreeBSD ostracod.unsane.co.uk 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #7 r209709M: Mon Jul 5 15:24:57 BST 2010 t...@ostracod.unsane.co.uk:/scratch/obj/usr/src/sys/OSTRACOD amd64 And its much improved, I'm no longer seeing timeouts. I am seeing occasional packet loss but as I mentioned previously I did from a 8.0-RELEASE live usb too. [r...@ostracod ~]# ping -c 1000 -i 0.1 -q 10.10.10.5 PING 10.10.10.5 (10.10.10.5): 56 data bytes --- 10.10.10.5 ping statistics --- 1000 packets transmitted, 928 packets received, 7.2% packet loss round-trip min/avg/max/stddev = 1.150/3.006/30.993/4.813 ms Vince ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/94863: [bge] [patch] hack to get bge(4) working on IBM e326m
Synopsis: [bge] [patch] hack to get bge(4) working on IBM e326m State-Changed-From-To: suspended->closed State-Changed-By: yongari State-Changed-When: Tue Jul 6 21:58:43 UTC 2010 State-Changed-Why: Close, BCM5780 support was made long time ago. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 21:58:43 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=94863 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/104485: [bge] Broadcom BCM5704C: Intermittent on newer chip version: CS0424 P20
Synopsis: [bge] Broadcom BCM5704C: Intermittent on newer chip version: CS0424 P20 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jul 6 22:03:44 UTC 2010 State-Changed-Why: Is it still issue on more recent FreeBSD?(8.1-RC2 or 7.3-RELEASE)? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 22:03:44 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=104485 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/107850: [bce] bce driver link negotiation is faulty
Synopsis: [bce] bce driver link negotiation is faulty State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jul 6 22:05:52 UTC 2010 State-Changed-Why: Is it still issue on more recent FreeBSD?(8.1-RC2 or 7.3-RELEASE)? I believe it was fixed in long time ago. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 22:05:52 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=107850 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/112570: [bge] packet loss with bge driver on BCM5704 chipset
Synopsis: [bge] packet loss with bge driver on BCM5704 chipset State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jul 6 22:10:08 UTC 2010 State-Changed-Why: Is it still issue on more recent FreeBSD?(8.1-RC2 or 7.3-RELEASE)? If yes, show me full verbose dmesg output as well as the outout of "pciconf -lcv". Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 22:10:08 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=112570 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/118879: [bge] [patch] bge has checksum problems on the 5703 chipset
Synopsis: [bge] [patch] bge has checksum problems on the 5703 chipset State-Changed-From-To: analyzed->closed State-Changed-By: yongari State-Changed-When: Tue Jul 6 22:15:29 UTC 2010 State-Changed-Why: As Kris pointed out, it's not a bug of bge(4). It's normal to see bad checksummed frames for out-going traffic on sender side as bpf listner sees frames before controller performs checksum calculation. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 22:15:29 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=118879 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/120232: [nfe] [patch] Bring in nfe(4) to RELENG_6
Synopsis: [nfe] [patch] Bring in nfe(4) to RELENG_6 State-Changed-From-To: open->closed State-Changed-By: yongari State-Changed-When: Tue Jul 6 22:18:10 UTC 2010 State-Changed-Why: jhb already MFCed nfe(4) into stable/6(r185644). Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 6 22:18:10 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=120232 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel 82574L Gigabit Ethernet Controller
Yow, 30 vlans, but only em1 is using vlans not em0? Is only em1 having watchdogs? I noticed you appear to have flow control off, maybe turning it on would help. I would like to see the log messages from the watchdogs. Jack On Tue, Jul 6, 2010 at 1:28 AM, Shtorm wrote: > On Mon, 2010-07-05 at 22:02 -0700, Jack Vogel wrote: > > Cleaner in the Makefile, let me know how it goes. > > > > Jack > > > > > > On Mon, Jul 5, 2010 at 12:06 PM, Yuriy A. Korobko > > wrote: > > > > > On Mon, 2010-07-05 at 11:11 -0700, Jack Vogel wrote: > > > > Are you defining 'EM_MULTIQUEUE', its off by default and needs to be > > > > defined somewhere by you. > > > > > > > > You will only see the two queues used if you have two different > > > connections > > > > operating at once. > > > > > > > > Jack > > Recompiled module (actually whole kernel) with EM_MULTIQUEUE, but got a > some watchdog timeouts. > > Here is example of netstat when it happens: > > 2346 0 0 583370 2642 02988379 0 > 2250 0 0 550961 2384 02835276 0 > 2634 0 0 703410 2733 02971417 0 > 2741 0 0 695884 2748 03061573 0 > 2811 0 0 618520 2274 03273868 0 > 3220 0 0 687145 2068 03417857 0 >901 0 0 231694166 01565839 0 >752 0 0 216135 0 0 270247 0 >685 0 0 208745 0 0 243442 0 >713 0 0 178089 0 0 230472 0 >735 0 0 159555 0 0 178435 0 >616 0 0 145222 0 0 179022 0 > input (em1) output > packets errs idrops bytespackets errs bytes colls > 616 0 0 129608 0 0 120929 0 >659 0 0 113806 0 0 105707 0 >622 0 0 106247 0 0 107825 0 >645 0 0 101593 0 0 38023 0 >483 0 0 61681 0 0 8547 0 > > Watchdog timeout on em1 message on console > > 0 0 0 0 0 1 19095 0 > 0 0 0 0 0 0222 0 > 0 0 0 0 0 0 0 0 >243 0 0 30224 1783 01708875 0 >576 0 0 62350105 0 7710 0 >467 0 0 49758 4 0 4388 0 >500 0 0 53415 23 0 24743 0 >437 0 0 50135 21 0 16733 0 > > After this traffic increased again up to 3 kpps and another watchdog > timeout happened. > > em0: flags=8843 metric 0 mtu > 1500 >options=2098 >ether 00:30:48:bc:ab:ca >inet x.x.x.x netmask 0xffe0 broadcast x.x.x.y >media: Ethernet autoselect (1000baseT ) >status: active > > em1: flags=8843 metric 0 mtu > 1500 >options=2098 >ether 00:30:48:bc:ab:cb >media: Ethernet autoselect (1000baseT ) >status: active > > em1 have 30 vlans and mpd5 as pppoe server listening on each vlan. > > Here is sysctl dev.em > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 > subdevice=0x10d3 class=0x02 > dev.em.0.%parent: pci1 > dev.em.0.nvm: -1 > dev.em.0.rx_int_delay: 200 > dev.em.0.tx_int_delay: 200 > dev.em.0.rx_abs_int_delay: 500 > dev.em.0.tx_abs_int_delay: 500 > dev.em.0.rx_processing_limit: 100 > dev.em.0.link_irq: 2 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.fc_high_water: 18432 > dev.em.0.fc_low_water: 16932 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 0 > dev.em.0.mac_stats.recv_no_buff: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.rx_overruns: 0 > dev.em.0.mac_stats.watchdog_timeouts: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 732916 > dev.em.0.mac_stats.good_pkts_recvd: 732916 > dev.em.0.mac_stats.bcast_pkts_recvd: 1238 > dev.em.0.mac_stats.mcast_pkts_recvd: 0 > dev.em.0.mac_stats.rx_frames_64: 84622 > dev.em.0.mac_stats.rx_frames_65_127: 128831 > dev.em.0.mac_stats.rx_frames_128_255: 34037 > dev.em.0.mac_stats.rx_frames_256_511: 30206 > dev.em.0.mac_stats.rx_frames_512_1023: 24919 > dev.em.0.mac_stats.rx_frames_1024_1522: 4
