On 01/18/17 00:34, O. Hartmann wrote: > On Thu, 5 Jan 2017 20:17:56 -0700 > Sean Bruno <sbruno_at_freebsd.org> wrote: > >> tl;dr --> igbX devices will become emX devices >> >> We're about to commit an update to sys/dev/e1000 that will implement and >> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks >> who can test and poke at the drivers to do so this week. This will have >> some really great changes for performance and standardization that have >> been bouncing around inside of various FreeBSD shops that have been >> collaborating with Matt Macy over the last year. >> >> This will implement multiple queues for certain em(4) devices that are >> capable of such things and add some new sysctl's for you to poke at in >> your monitoring tools. >> >> Due to limitations of device registration, igbX devices will become emX >> devices. So, you'll need to make a minor update to your rc.conf and >> scripts that manipulate the network devices. >> >> UPDATING will be bumped to reflect these changes. >> >> MFC to stable/11 will have a legacy implementation that doesn't use >> IFLIB for compatibility reasons. >> >> A documentation and man page update will follow in the next few days >> explaining how to work with the changed driver. >> >> sean >> >> bcc net_at_ current_at_ re_at_ >> >> >> > On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can > still trigger this behaviour on recent CURRENT (12.0-CURRENT #17 r312369: Wed > Jan 18 06:18:45 CET 2017 amd64) by rsync'ing a large poudriere ports > repository onto a remote NFSv4 fileserver. The freeze always occur on large > tarballs. > > Again, here is the pciconf output of the device: > > em0_at_pci0:0:25:0: class=0x020000 card=0x11ed1734 chip=0x153a8086 > rev=0x05 hdr=0x00 vendor = 'Intel Corporation' > device = 'Ethernet Connection I217-LM' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xfb300000, size 131072, enabled > bar [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled > bar [18] = type I/O Port, range 32, base 0xf020, size 32, enabled > > On another box. equipted with a dual-port Intel i350 NIC, the igb0 and igb1 do > have negotiation problems with several types of switches (in my SoHo > environment, I use a Netgear GS110TP, at work there are several types of Cisco > Catalyst 3XXX types). The igbX very often fall back to 100MBit/s. > > Since yesterday, the igbX on that specific i350 basesd NIC (we have plentz of > them and they show similar phenomena with FreeBSD), although the switch reports > an uplink with 1 GBit, FreeBSD CURRENT shows this weird crap message: > >> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu >> 1500 >> options=653dbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> >> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xffffff00 broadcast >> 192.168.0.255 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >> media: Ethernet autoselect (100baseTX <full-duplex>) >> status: active > > I haven't checked whether FreeBSD lies or the switch lies about the linkspeed, > but will do next time I have access to the box. > > > regards, > Oliver > Ugh. Ok. Investigating the link issue, that's gross. sean
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC