From owner-freebsd-stable@FreeBSD.ORG Thu Oct 31 08:25:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 337BC7D1 for ; Thu, 31 Oct 2013 08:25:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0874628DE for ; Thu, 31 Oct 2013 08:25:42 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rp16so2496514pbb.3 for ; Thu, 31 Oct 2013 01:25:41 -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-type:content-disposition:in-reply-to:user-agent; bh=OZcm6YE2o4UPJZO4m1GsBe07SbXcBVVJu38YopUqLTo=; b=Gsq9YGBDPq+4BHP8VBn2Ok46PoOsW9hFAjpvDAM3s1vuia3h13ZaK9jXifIwb/quI4 qKTPaavYI/oeHXLTV+nVHf8pyDZqNwx3ag/o116BiuArTB/cAGobtq0N638U67x/81yS 5lOIW8DUUuUdtfH+cg/e5YIvewrYKFUBj/J0thSYdpqmfaGHi56nDkWPPB4ZmQK9aKu4 q6POZp6DPWZSeymcFIWbTYQCdEIB+cmYulXXMC4q1eaIPH/dvXBzmjiVZO+2lS9G4Yrt W9kI9pOXCM5DpCD0JSA5bPUtQ5BJN9uun2IRgPhYqMOwK2UeJw07xcnbGFihTfhp55su E8vg== X-Received: by 10.66.154.1 with SMTP id vk1mr619356pab.85.1383207941726; Thu, 31 Oct 2013 01:25:41 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id tu6sm2455436pbc.41.2013.10.31.01.25.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 31 Oct 2013 01:25:40 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 31 Oct 2013 17:25:35 +0900 From: Yonghyeon PYUN Date: Thu, 31 Oct 2013 17:25:35 +0900 To: Oliver Fromme Subject: Re: re(4) problems with GA-H77N-WIFI Message-ID: <20131031082535.GA1386@michelle.cdnetworks.com> References: <20130213013438.GA3101@michelle.cdnetworks.com> <201302131450.r1DEoGb3098019@grabthar.secnetix.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <201302131450.r1DEoGb3098019@grabthar.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@FreeBSD.ORG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 08:25:42 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 13, 2013 at 03:50:16PM +0100, Oliver Fromme wrote: > YongHyeon PYUN wrote: > > On Fri, Feb 08, 2013 at 08:27:55PM +0100, Oliver Fromme wrote: > > > re0: CMD 0x0c > > > re0: link state changed to UP > > > re0: link state changed to DOWN > > > re1: link state changed to UP > > > re1: link state changed to DOWN > > > re1: CMD 0x0c > > > re1: link state changed to UP > > > re0: CMD 0x0c > > > re0: link state changed to UP > > > re1: link state changed to DOWN > > > > > > I always seem to get 0x0c for both re0 and re1. > > > > Hmm, it seems GMAC is in sane state. > > Would you show me the output of "devinfo -rv | grep rgephy"? > > rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x5 at phyno=1 > rgephy1 pnpinfo oui=0xe04c model=0x11 rev=0x5 at phyno=1 > > > To rule out hardware issues, could you also try other OS like > > Linux? > > Ok, I'll look for a small Linux image that can be booted > from a USB stick ... > Sorry for reviving old thread. Could you try attached patch and let me know how it goes? I'm not seeing the issue on 8168EV-L engineering sample board but it seems some BIOSes are broken in a couple of situations. --SUOF0GtieIMvvwua Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.8168evl.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 257422) +++ sys/dev/re/if_re.c (working copy) @@ -295,6 +295,8 @@ static int re_miibus_writereg (device_t, int, int, int); static void re_miibus_statchg (device_t); +static void re_eri_write (struct rl_softc *, bus_size_t, uint32_t, int); + static void re_set_jumbo (struct rl_softc *, int); static void re_set_rxmode (struct rl_softc *); static void re_reset (struct rl_softc *); @@ -641,6 +643,32 @@ } /* + * ERI is used to access extended GigaMAC register. addr should be + * aligned on 4 bytes boundary. mask(e.g. bit 12~15 of RL_ERIAR) is + * used to determine which bytes in RL_ERIDR should be accessed. + * Because we have to access 32bits quantity regardless of the value + * of mask, make driver access to 4 bytes which in turn means it's + * responsibility of caller to preserve unwanted bytes in write + * access. + */ +static void +re_eri_write(struct rl_softc *sc, bus_size_t addr, uint32_t val, int type) +{ + int i; + + CSR_WRITE_4(sc, RL_ERIDR, val); + CSR_WRITE_4(sc, RL_ERIAR, addr | type | RL_ERIAR_BYTES_MASK | + RL_ERIAR_WRITE); + for (i = 100; i > 0; i--) { + DELAY(100); + if ((CSR_READ_4(sc, RL_ERIAR) & RL_ERIAR_BUSY) == 0) + break; + } + if (i == 0) + device_printf(sc->rl_dev, "%s: timed out\n", __func__); +} + +/* * Set the RX configuration and 64-bit multicast hash filter. */ static void @@ -3047,6 +3075,7 @@ struct mii_data *mii; uint32_t reg; uint16_t cfg; + uint8_t *ea; union { uint32_t align_dummy; u_char eaddr[ETHER_ADDR_LEN]; @@ -3155,6 +3184,23 @@ htole32(*(u_int32_t *)(&eaddr.eaddr[0]))); CSR_WRITE_4(sc, RL_IDR4, htole32(*(u_int32_t *)(&eaddr.eaddr[4]))); + if (sc->rl_hwrev->rl_rev == RL_HWREV_8168E_VL) { + /* + * It seems extended GigaMAC registers are not correctly + * initialized in situations like cold boot or resume. + * Reprogram extended GigaMAC registers to set our + * station address. + */ + ea = IF_LLADDR(ifp); + re_eri_write(sc, 0xE0, ea[3] << 24 | ea[2] << 16 | ea[1] << 8 | + ea[0], RL_ERIAR_EXGMAC); + re_eri_write(sc, 0xE4, ea[5] << 24 | ea[4] << 16, + RL_ERIAR_EXGMAC); + re_eri_write(sc, 0xF0, ea[1] << 24 | ea[0] << 16, + RL_ERIAR_EXGMAC); + re_eri_write(sc, 0xF4, ea[5] << 24 | ea[4] << 16 | ea[3] << 8 | + ea[2], RL_ERIAR_EXGMAC); + } CSR_WRITE_1(sc, RL_EECMD, RL_EEMODE_OFF); /* Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 257422) +++ sys/pci/if_rlreg.h (working copy) @@ -143,6 +143,8 @@ #define RL_MACDBG 0x006D /* 8 bits, 8168C SPIN2 only */ #define RL_GPIO 0x006E /* 8 bits, 8168C SPIN2 only */ #define RL_PMCH 0x006F /* 8 bits */ +#define RL_ERIDR 0x0070 +#define RL_ERIAR 0x0074 #define RL_MAXRXPKTLEN 0x00DA /* 16 bits, chip multiplies by 8 */ #define RL_INTRMOD 0x00E2 /* 16 bits */ @@ -545,6 +547,19 @@ #define RL_GMEDIASTAT_TXFLOW 0x40 /* TX flow control on */ #define RL_GMEDIASTAT_TBI 0x80 /* TBI enabled */ +#define RL_ERIAR_BYTES_1ST 0x00001000 +#define RL_ERIAR_BYTES_2ND 0x00002000 +#define RL_ERIAR_BYTES_3RD 0x00004000 +#define RL_ERIAR_BYTES_4TH 0x00008000 +#define RL_ERIAR_BYTES_MASK 0x0000F000 +#define RL_ERIAR_EXGMAC 0x00000000 +#define RL_ERIAR_MSIX 0x00010000 +#define RL_ERIAR_ASF 0x00020000 +#define RL_ERIAR_READ 0x00000000 +#define RL_ERIAR_WRITE 0x80000000 +#define RL_ERIAR_BUSY 0x80000000 +#define RL_ERIAR_READY 0x80000000 + /* * The RealTek doesn't use a fragment-based descriptor mechanism. * Instead, there are only four register sets, each or which represents --SUOF0GtieIMvvwua--