https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208205
Ralf Wostrack <ralf.wostr...@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ralf.wostr...@gmx.de
--- Comment #32 from Ralf Wostrack <ralf.wostr...@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=0x020000 card=0xe0001458 chip=0x816810ec rev=0x0c
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
re1@pci0:4:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x0c
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = 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 = xsc;
RL_LOCK_ASSERT(sc);
mii = device_get_softc(sc->rl_miibus);
mii_tick(mii);
if ((sc->rl_flags & RL_FLAG_LINK) == 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);
}
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
