Date: Tue, 25 Oct 2016 10:13:04 +0900 From: "Lundberg, Johannes" <johannes@brilliantservice.co.jp> To: FreeBSD Current <freebsd-current@freebsd.org> Subject: WRITE_FPDMA_QUEUED error when installing on MBP 2014 Message-ID: <CAASDrV=yp1sqU3gX%2B0SU=QjSdnkWMtbErP6WrwrWfpU3GymUdg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
SGkgQWxsDQoNCkkgcmVhZCB0aGF0IHBlb3BsZSBzdWNjZXNzZnVsbHkgaW5zdGFsbGVkIEZyZWVC U0Qgb24gMjAxNCdzIE1hY0Jvb2sgUHJvcy4NCg0KSSBqdXN0IGdvdCBhIHVzZWQgbWFjaGluZSAo aW4gZXhjZWxsZW50IHNoYXBlKSBhbmQgdHJ5IHRvIGluc3RhbGwgRnJlZUJTRA0KY3VycmVudCBm cm9tIFVTQiBtZW1vcnkgYmVzaWRlcyBPU1ggYW5kIExpbnV4Lg0KDQpFdmVyeSB0aW1lIHVucGFj a2luZyBmYWlscyB3aXRoIFdSSVRFX0ZQRE1BX1FVRVVFRCB0aW1lb3V0IGVycm9yLg0KDQpJJ20g d29ycmllZCB0aGF0IHRoZSBTU0QgY2FuIGJlIGRhbWFnZWQgc28gSSBsaWtlZCB0byBjb25maXJt IGlmIGFueW9uZQ0Ka25vd3MgaWYgdGhlcmUgaXMgYW55IGtub3duIGlzc3VlcyBsaWtlIHRoaXM/ IFRoZSBlcnJvciBpcyByZXBvcnRlZCBmb3IgYWRhDQphbmQgbm90IGRhIGJ1dCBjb3VsZCBpdCBi ZSBhIHNvdXJjZSBlcnJvciAoVVNCIG1lbW9yeSwgZG93bmxvYWRlZCBtZW1zdGljaw0KaW1hZ2Up Pw0KDQpBICdkZCBpZj0vZGV2L3NkYSBvZj0vZGV2L251bGwnIHNob3cgbm8gZXJyb3Igb24gTGlu dXguIFdpbGwgdHJ5IEZyZWVCU0QNCm5leHQuDQoNCkdyYXRlZnVsIGZvciBhbnkgZmVlZGJhY2su DQoNClRoYW5rcyENCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOBk+OBrumbu+WtkOOD oeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOBp+OBguOCiuOAgeen mOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OBp+OBhOOBvuOBmeOA ggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXjgozjgZ/loLTlkIjj gIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7jg6Hjg7zjg6vjgavp lqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu5LuW44Gu 5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL44Gq44KL6KGM 5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+44GZ44CCCi0t LQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaXMg Y29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuCkRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0aW9uIG9mIHVzZSBv ZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lwaWVudCwgaXMg cHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJveSB0aGUgb3JpZ2lu YWwgbWVzc2FnZS4K From owner-freebsd-current@freebsd.org Tue Oct 25 02:05:45 2016 Return-Path: <owner-freebsd-current@freebsd.org> 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 2312EC1EED4 for <freebsd-current@mailman.ysv.freebsd.org>; Tue, 25 Oct 2016 02:05:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 F1A231CD for <freebsd-current@freebsd.org>; Tue, 25 Oct 2016 02:05:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf0-x231.google.com with SMTP id 128so109423624pfz.0 for <freebsd-current@freebsd.org>; Mon, 24 Oct 2016 19:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=FHzkiSkFQaacx/n1GnMg4EcghWN95BhLKYqzUocIbBA=; b=Zw03Hm4+CHdlED17xCbjiY6cRHBLRnhtM4LiroDk5RkwmD1pmRKEDolcv8rp/CqhbT tvC569mSGlaMILIY5GIUQ947i3jcECc/THq0rdJv1vEZzcpL3Sz7ivIo8QUgfJO6GT3s wKJUuhZDo+KXVfRTt+FNi3zo26dhAQOAWiSsiq7Gkvp2kC7APJCSXNCsSSBzWyuyYkAZ owk/u4rEgn/JylH/4PY+wD9pSoS1JELrXPJagYeu5tY6XpCxxKEO4A688abXtccuik5D RdIpQec8nnK+cJKUAibTduBX5zhQUjLA8XvC/5Oomxlfw8kpKInaHGpvYvICoAyw20Pk LTpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=FHzkiSkFQaacx/n1GnMg4EcghWN95BhLKYqzUocIbBA=; b=R4EPcxbkViwMB2BNoMs8Cd4UPQhCsmpoJT+G1akOaJ5GT8aRTihIHGFkqmaia+Jw6u VJ9RgNwYHSpK6/BrC/kZJvMbFjrCiH/VAoDF7luiUpCdevAlwgcG+DEEUODnU7aBSA7y kkBmmRlMJ88ZjPEn91JM9rlXxU5cr0K2EzHYLQKd52OtQ9i8h8725t+pY5otRa2LJ9a5 CJoPBH4r1shADei4KXfHLw39on+x6zf3jR2BOvojsBQpLiBNNxSRXZNoS83PkymUbxtZ Am0tImZJN/teXiyEFwajCS47lYT7owYezR69qhrOGg3sw7Na1ck9tzZcyt1YMqNxbMO4 zIqA== X-Gm-Message-State: ABUngvf/DwjkZDUj0ksxhrx3J7ILxy+Qw+G8cocz/ZWhhQNGHtv2gOMftVCY/lu4e0NeFw== X-Received: by 10.98.194.68 with SMTP id l65mr34958161pfg.159.1477361144271; Mon, 24 Oct 2016 19:05:44 -0700 (PDT) Received: from localhost ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id x1sm28291735pax.7.2016.10.24.19.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 19:05:43 -0700 (PDT) From: YongHyeon PYUN <pyunyh@gmail.com> X-Google-Original-From: "YongHyeon PYUN" <yongari@gmail.com> Received: by localhost (sSMTP sendmail emulation); Tue, 25 Oct 2016 11:05:38 +0900 Date: Tue, 25 Oct 2016 11:05:38 +0900 To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161025020538.GA1238@michelle.fasterthan.co.kr> Reply-To: pyunyh@gmail.com References: <20161023132538.6bf55fb2@hermann> <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 25 Oct 2016 02:05:45 -0000 On Mon, Oct 24, 2016 at 02:03:37PM +0200, O. Hartmann wrote: > On Mon, 24 Oct 2016 14:14:00 +0900 > YongHyeon PYUN <pyunyh@gmail.com> wrote: > > > On Sun, Oct 23, 2016 at 01:25:38PM +0200, Hartmann, O. wrote: > > > 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. > > > > > > > There were several instability reports on re(4). I vaguely guess > > it would be related with some missing initializations for certain > > controllers. Unfortunately, there is no publicly available > > datasheet for those controllers and it's not likely to get access > > to it in near future. It seems vendor's FreeBSD driver accesses > > lots of magic registers as well as loading DSP fixups. I have no > > idea what it wants to do and re(4) used to heavily rely on power-on > > default register values. Engineering samples I have do not show > > instabilities so it wouldn't be easy to identify the issue. > > > > Probably the first step to address the issue would be identifying > > those chips and narrowing down the scope of guessing. Would you > > show me the dmesg output(re(4) and regphy(4) only)? pciconf(8) > > output is useless here since RealTek uses the same PCI id for > > PCIe variants. > > > > BTW, I was told that the vendor's FreeBSD driver seems to work fine > > for normal usage pattern. The vendor's driver triggered an instant > > panic and lacked H/W offloading features in the past. It might > > have changed though. > > The problemacy with re(4) drivers arose again, when I bought some "green" > equipment, mainly switches, which reduces power emission on short cables or > non-connected ports. This brought down some servers with re(4) chipsets > immediately and I had no clue what happend. I do not know whether this is a I'm not sure but it's likely the issue is related with EEE/Green Ethernet handling. EEE is negotiated feature with link partner. If you directly connect your laptop to non-EEE capable link partner like other re(4) box without switches you may be able to tell whether the issue is EEE/Green Ethernet related one or not. > single fate so to speak, or this problem will arise for others, too. We > exchanged on serving hardware all Realtek NICs with those from Intel, and > luckily some server mainboards already have Intel PHY or NICs. The Broadcom > devices we have on some older Fujitus hardware is also stable like a charme, > even with the new power saving switches. > bge(4) also lacks EEE support(Publicly available datasheet is too sanitized one). bge(4) firmware probably does not announce EEE capability by default in link establishment while recent re(4) devices seem to unconditionally announce EEE. Generally EEE handling requires a kind of handshake for link state change from MAC/PHY. > While we can swap on server or workstation platforms the NIC, it is almost > impossible on laptops and the number of laptops with realtek chips seems to > grow. It is a pity that the venodr of the chipsets reject supporting other OSes > than Windows - or in some rare cases only Linux. After you wrote the answer, I > checked on the net who's suiatble drivers and the situation seems bad for > almost all OSes apart from commercial ones like Windooze and Apple OS X. > > As soon as I get hands on the laptop again, I'll send the requested > informations. I know that I played around with re(4) and rgephy(4) in the > kernel, the rgephy(4) showed up on the dmesg, but I didn't see any effect - > except that it offered some additional "media xxx-options-xxx" mostly appended > with "flow" - but rying brought also down the system as pluggin or unplugging. rgephy(4) will show recognized PHY H/W model. Another information I'd like to know is OUI information of the PHY. The OUI information could be get with `devinfo -rv | grep rgephy`. The "flow" output of media indicates it negotiated ethernet flow-control with link partner. rgephy(4) used to announce autonegotiation even when manual setting is requested with ifconfig. It was to workaround HW issues seen in the past. You can disable the use of autonegotiation in manual media selection with flag0 option. See rgephy(4) for more information. Not sure whether that option helps though. > The last kernel I compiled was then without rgephy(4) - the NIC worked as > expected, but pluggin/unplugging or having some power-down activities on a > Netgear SoHo green-pwer switch brings the system down as usual. If you use re(4) without rgephy(4) it will use ukphy(4) which is completely dumb on link state detection of re(4) controller. Link state detection requires non-PHY register access on re(4) so using ukphy(4) is not recommended.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAASDrV=yp1sqU3gX%2B0SU=QjSdnkWMtbErP6WrwrWfpU3GymUdg>