Date: Wed, 02 May 2018 15:51:46 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 166724] [re] if_re watchdog timeout Message-ID: <bug-166724-7501-am7e4V9Ezi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-166724-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-166724-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=3D166724 Arto Pekkanen <aksyom@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aksyom@gmail.com --- Comment #23 from Arto Pekkanen <aksyom@gmail.com> --- I managed to solve this issue by disabling MSI and MSI-X. Put the following lines into /boot/loader.conf hw.re.msi_disable=3D"1" hw.re.msix_disable=3D"1" You see, the MSI/MSI-X interrupt processing supposedly eliminates the need = to perform an extra read from device register after receiving an interrupt whi= ch tells that a DMA write is finished. However, there is some kind of problem either in the driver or the chip itself in the way it handles these interru= pts. By disabling MSI and MSI-X, the driver switches to using the older interrupt filter handler, and thus probably performs and extra read from some device register to wait for the DMA transfer to memory to be ready (according to wikipedia, when using legacy interrupts this is the only way to ensure the = DMA transfer wasn't buffered by the chipset etc). So, I would suggest everybody watching this thread to try if disabling MSI = and MSI-X on their system helps. Might not apply to all Realtek NICs, but on my machine this workaround is valid. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-166724-7501-am7e4V9Ezi>