Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Jun 2021 11:57:27 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 256375] iflib/if_em: unplugging network cable causes huge KTorrent slowdown
Message-ID:  <bug-256375-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256375

            Bug ID: 256375
           Summary: iflib/if_em: unplugging network cable causes huge
                    KTorrent slowdown
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Keywords: iflib, performance
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: net@FreeBSD.org
          Reporter: danfe@FreeBSD.org

Created attachment 225494
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D225494&action=
=3Dedit
procstat -kk output

I'm experiencing strange and very prominent performance loss with KTorrent =
when
unplugging Ethernet cable from em0, that is, switch to WiFi: it now takes
several tens seconds for it to update the window contents, react to mouse
clicks, and transfer speeds drop down to single bytes per second.  At this
time, the ktorrent process, as displayed by top(1), is in "iflib" state whi=
ch
occasionally briefly changes to "e1000_".

But once I plug the network cable back, everything goes back to normal, and=
 the
process returns to "select" state like it should.  This happens on Lenovo L=
470
laptop with the following NIC:

em0@pci0:0:31:6:        class=3D0x020000 rev=3D0x21 hdr=3D0x00 vendor=3D0x8=
086
device=3D0x15d8 subvendor=3D0x17aa subdevice=3D0x505f
    vendor     =3D 'Intel Corporation'
    device     =3D 'Ethernet Connection (4) I219-V'
    class      =3D network
    subclass   =3D ethernet

Both today's kernel and my normal Jan/Feb'ish kernel behave identically.  T=
he
driver from `net/intel-em-kmod' port does not exhibit this problem.  I'm
attaching procstat -kk $ktorrent_pid output, in case it could be useful.  T=
his
line looks suspicious as if something is holding the lock:

mi_switch+0xc1 _sx_xlock_hard+0x3d1 iflib_media_status+0xf2 ifmedia_ioctl+0=
x16a
ifhwioctl+0x2bd ifioctl+0x48d kern_ioctl+0x23b sys_ioctl+0xf6
amd64_syscall+0x100 fast_syscall_common+0xf8

Please advise on any other debug information I could provide which may help=
 to
track the bug down and fix it.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256375-7501>