On 01/18/17 00:34, O. Hartmann wrote:
> On Thu, 5 Jan 2017 20:17:56 -0700
> Sean Bruno <sbr...@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@ current@ re@
> 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@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
>> ether xx:xx:xx:xx:xx:xx inet netmask 0xffffff00 broadcast
>>        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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to