From owner-freebsd-current@freebsd.org Sun Oct 23 11:28:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6464EC1E593 for ; Sun, 23 Oct 2016 11:28:57 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 2AE2BB11 for ; Sun, 23 Oct 2016 11:28:56 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1byGuJ-0025FJ-N4>; Sun, 23 Oct 2016 13:25:39 +0200 Received: from x4e3481f4.dyn.telefonica.de ([78.52.129.244] helo=hermann) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1byGuJ-000hRs-EC>; Sun, 23 Oct 2016 13:25:39 +0200 Date: Sun, 23 Oct 2016 13:25:38 +0200 From: "Hartmann, O." To: FreeBSD CURRENT Subject: CURRENT: re(4) crashing system Message-ID: <20161023132538.6bf55fb2@hermann> Organization: FU Berlin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 78.52.129.244 X-Mailman-Approved-At: Sun, 23 Oct 2016 11:32:50 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 11:28:57 -0000 I tried to report earlier here that CURRENT does have some serious problems right now and one of those problems seems to be triggered by the recent re(4) driver. The problem is also present in recen 11-STABLE! Below, you'll find pciconf-output reagrding the device on a Lenovo E540 Laptop I can test on and trigger the problem. The phenomenon is that this NIC does not negotiate 1000baseTX, it is always falling back to 100baseTX although the device claims to be a 1 GBit capable device. When I try to put the device manually into 1000basTX mode via ifconfig re0 media 1000baseTX mediaopt full-duplex (with re(4) driver) it is possible to crash the system. The system also crashes when plugging/unplugging the LAN cord - I guess the renegotiation is triggering this crash immediately. I tried with several switches and routers capable of 1 GBit and it seems to be independent from the network hardware in use. I tried to capture a backtrace when the kernel crashes, but I do not know how to save the the kernel debugger output. Although I configured according the handbook debugging, there is no coredump at all. Advice is appreciated - if anybody is interesetd in solving this. Thank you very much in advance and kind regards, Oliver [...] re0@pci0:3:0:0: class=0x020000 card=0x502817aa chip=0x816810ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled bar [18] = type Memory, range 64, base 0xf0d04000, size 4096, enabled bar [20] = type Memory, range 64, base 0xf0d00000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint MSI 1 max data 128(128) RO link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 01000000684ce000 ecap 0018[170] = LTR 1 ecap 001e[178] = unknown 1