From owner-freebsd-hackers@freebsd.org Tue Apr 24 16:48:54 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 B88D2FABA8E for ; Tue, 24 Apr 2018 16:48:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F91C74A68 for ; Tue, 24 Apr 2018 16:48:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id u62-v6so15914038ita.5 for ; Tue, 24 Apr 2018 09:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5+kaMjY3ouzM5ewPN7p6awyzMrDidkiHeiw075ZN7Dg=; b=zNhSS2p6WiDpCvg7eKHrgZkmpYoGpdW4Qc1TJS0wtZaSJupPgh4Zi786a1Nle3fM+p HF7gAaQo91xzuIv83cZKRfVT2pC/INrBUzkD/rhK4Tg6qPwDoQCrC8O9wyoLWL8LkZ7R nituwQTiCEA6FaOB38O/yZnTDcBLWOJhP7qJnlr1DlSUzLZF6Z8tg115Dkcu/Fx2NjK3 OI0hOzVErO7l/fANxWcaKoEKOoRQKTpQHXrE9YrwgSa75fTtIS2o4LCEt/z8YpSl+Z5O PXQuXORyQsaykjt6SOyCaSIvfYwGIzBt8hfq6tMg0qAZtEUaV+hzFdtvLAHHnzZ4cLMY qylw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5+kaMjY3ouzM5ewPN7p6awyzMrDidkiHeiw075ZN7Dg=; b=RgTHOrQGHwk7OKdelahIwnDkxamfGX+3lwO9zcu0s8quKt/tL/KvSNxEkE7e1b3N6W /TC6YbgfdjFujQg6SHQQ9rfB19axJ9Ctlc6/4fJWpgRQLpNKKohzpN7DmPJvau47wSaU BrVTWruYGdUQVuW9an4UA6FDAE2svhtduGoYdvfS+ZlvoIy93h0Qq96oAVfmEgAR7u6v kWU8ArihWpHWG+W6LkksGsEe5vBwGa/Tp5Lrk4hXt/juXY3cDdlP9JpwgOu/UPKQppLB nr3eoDLv98trL++qoSi/klV519O/j/beH09xQEOkKbr+pN4HgeqgvDYHvYmHccHpZsGx 2hVg== X-Gm-Message-State: ALQs6tA2is2Vev8EL0u/q4IvP31NEtK5qYQVjpEfEh9q/GfYfRmWzNxm shKMz5nxNcgAsz5OedL17Lc4cwTdT6RcwnHJSAebcw== X-Google-Smtp-Source: AB8JxZoMDMI0htkxbD1nbhhdJ5RtB6wJlzUTndgbLQpO282uYnFmHgEJ3rlEN/rxVzTDUPWxa74Mm2Cob5XZAyZ4r3s= X-Received: by 2002:a24:1fc7:: with SMTP id d190-v6mr18186809itd.57.1524588533227; Tue, 24 Apr 2018 09:48:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a604:0:0:0:0:0 with HTTP; Tue, 24 Apr 2018 09:48:51 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <723a1947-5258-9654-2d1b-5b2ff29aecb8@alexdupre.com> 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> <723a1947-5258-9654-2d1b-5b2ff29aecb8@alexdupre.com> From: Warner Losh Date: Tue, 24 Apr 2018 10:48:51 -0600 X-Google-Sender-Auth: S4BnCsAOsBtGB2RMEnFbO2nWvUs Message-ID: Subject: Re: Realtek re(4) driver To: Alex Dupre Cc: "freebsd-hackers@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 16:48:55 -0000 On Tue, Apr 24, 2018 at 7:48 AM, Alex Dupre wrote: > 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). > The rl/re cards have some code in them to cope with cable length to the hub, since on the older cards this can greatly increase reliability. Perhaps there's signal issue here? Also, the re drivers are known to have some revs that have hardware offload features, but that said features don't work. Ideally, if you had a completely reproducible scenario you could turn off all the hardware offload and see if that fixes the problem. Warner