Date: Tue, 24 Apr 2018 15:48:37 +0200 From: Alex Dupre <sysadmin@alexdupre.com> To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <723a1947-5258-9654-2d1b-5b2ff29aecb8@alexdupre.com> In-Reply-To: <20180424083449.GB11959@britannica.bec.de> References: <CAA3ZYrCdBWi%2BXSge%2BYfDH73a5QpaK0oOVTABb2k16NA5xUx%2BdA@mail.gmail.com> <f76f167d-c37f-3673-11c3-094a3fb13186@multiplay.co.uk> <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> <20180424083449.GB11959@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Joerg Sonnenberger wrote: > The most likely cause of any problem here is a missing workaround for a > hardware bug or Realtek deciding that some specific tuning is necessary > for certain chips. It is nearly impossible to fix this kind of bugs > without having access to the hardware and a way to reproduce it. > Comparing with a working driver might be possible, but it is extremely > tideous. I've just setup two machines with re interfaces (one onboard and one with an external pci-ex card), connected point to point, but I was unable to reproduce the issue. I can easily reproduce it on another server, but that's a semi-production one, so I can do limited testing (ie replace the if_re.ko kernel module, reboot, and do something for a few minutes, then I have to revert to the working kernel module). -- Alex Dupre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?723a1947-5258-9654-2d1b-5b2ff29aecb8>