From owner-freebsd-hackers@freebsd.org Tue Apr 24 13:55:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2DD3FA5456 for ; Tue, 24 Apr 2018 13:55:23 +0000 (UTC) (envelope-from sysadmin@alexdupre.com) Received: from lab.alexdupre.com (lab.alexdupre.com [93.151.207.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C480698A1 for ; Tue, 24 Apr 2018 13:55:22 +0000 (UTC) (envelope-from sysadmin@alexdupre.com) Received: (qmail 71154 invoked from network); 24 Apr 2018 13:48:38 -0000 Received: from 151-0-207-195.ip282.fastwebnet.it (HELO ale.bitgold.com) (sysadmin@alexdupre.com@151.0.207.195) by lab.alexdupre.com with ESMTPSA; 24 Apr 2018 13:48:38 -0000 Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <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> From: Alex Dupre Message-ID: <723a1947-5258-9654-2d1b-5b2ff29aecb8@alexdupre.com> Date: Tue, 24 Apr 2018 15:48:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180424083449.GB11959@britannica.bec.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Apr 2018 16:25:22 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 13:55:23 -0000 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