Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Feb 2020 06:33:46 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 208205] re0 watchdog timeout
Message-ID:  <bug-208205-7501-vVFjiJlqk2@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-208205-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-208205-7501@https.bugs.freebsd.org/bugzilla/>

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

Ralf Wostrack <ralf.wostrack@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ralf.wostrack@gmx.de

--- Comment #32 from Ralf Wostrack <ralf.wostrack@gmx.de> ---
Hi,

starting from version 12.0, i facing this issue on my mini-itx server.

Hardware Info:
re0@pci0:3:0:0: class=3D0x020000 card=3D0xe0001458 chip=3D0x816810ec rev=3D=
0x0c
hdr=3D0x00
    vendor     =3D 'Realtek Semiconductor Co., Ltd.'
    device     =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll=
er'
    class      =3D network
    subclass   =3D ethernet
re1@pci0:4:0:0: class=3D0x020000 card=3D0xe0001458 chip=3D0x816810ec rev=3D=
0x0c
hdr=3D0x00
    vendor     =3D 'Realtek Semiconductor Co., Ltd.'
    device     =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll=
er'
    class      =3D network
    subclass   =3D ethernet

I solved it, by commenting out re_txeof in re_tick function in if_re.c.
In my oppinion its a timing issue during high load situtations, blocking the
interrupt/dma of the device.
And of course the job is done by watchdog function after 5 timer ticks.

static void
re_tick(void *xsc)
{
        struct rl_softc         *sc;
        struct mii_data         *mii;

        sc =3D xsc;

        RL_LOCK_ASSERT(sc);

        mii =3D device_get_softc(sc->rl_miibus);
        mii_tick(mii);
        if ((sc->rl_flags & RL_FLAG_LINK) =3D=3D 0)
                re_miibus_statchg(sc->rl_dev);
        /*
         * Reclaim transmitted frames here. Technically it is not
         * necessary to do here but it ensures periodic reclamation
         * regardless of Tx completion interrupt which seems to be
         * lost on PCIe based controllers under certain situations.
         */
        // re_txeof(sc);
        re_watchdog(sc);
        callout_reset(&sc->rl_stat_callout, hz, re_tick, sc);
}

--=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-208205-7501-vVFjiJlqk2>