Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Feb 2022 21:54:22 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 262024] em(4)/iflib handles bad packets incorrectly
Message-ID:  <bug-262024-227@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 262024
           Summary: em(4)/iflib handles bad packets incorrectly
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: erj@freebsd.org

We saw an issue where the em(4) interface would flap repeatedly, and the ro=
ot
cause was that the SBP flag was enabled, causing the hardware to send bad
packets to the driver.

It appears that if the driver's isc_rxd_pkt_get() handler (e.g. in em here:
https://cgit.freebsd.org/src/tree/sys/dev/e1000/em_txrx.c#n692) returns EBA=
DMSG
(because the hardware said the packet was bad), the iflib function that cal=
ls
that will immediately jump to resetting the hardware.

We don't think that this should be the case (especially if the driver is
explicitly allowing bad packets) and think it should be changed.

A previous bug report/commit changed the em(4) driver's default SBP setting=
 to
false, so that future users probably won't encounter this behavior unless t=
hey
manually set it back to true.

In this case we've seen it em(4) specifically, but it could affect other
iflib-using drivers that allow hardware to forward bad packets to the drive=
r.

--=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-262024-227>