Date: Sat, 23 Jan 2010 15:46:35 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Shteryana Shopova <syrinx@freebsd.org> Cc: freebsd-net@freebsd.org, yongari@freebsd.org Subject: Re: i386/142974: [patch][net][if_re] Teach the if_re driver to properly recognize hardware revisions with non-zero MAC rev. bits Message-ID: <20100123234635.GH20753@michelle.cdnetworks.com> In-Reply-To: <61b573981001230542l59a9ab6y26514a213bfbdb67@mail.gmail.com> References: <201001221959.o0MJxnIs016854@freefall.freebsd.org> <61b573981001230542l59a9ab6y26514a213bfbdb67@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 23, 2010 at 03:42:55PM +0200, Shteryana Shopova wrote: > Hi, > > On Fri, Jan 22, 2010 at 9:59 PM, <yongari@freebsd.org> wrote: > > Synopsis: [patch][net][if_re] Teach the if_re driver to properly recognize hardware revisions with non-zero MAC rev. bits > > > > State-Changed-From-To: open->feedback > > State-Changed-By: yongari > > State-Changed-When: Fri Jan 22 19:57:19 UTC 2010 > > State-Changed-Why: > > It looks like you have second generation RTL8168C PCIe controller. > > If I understand correctly the RTL8168C PCIe is a Gigabit Ethernet > controller and mine's definately a Fast Ethernet > > > I guess hwrev variable would have value 0x34c00000 and I don't see > > reason why it can't match an entry in re_hwrevs table which already > > has that entry. > > Well, actually there's no 0x34C00000 in the Known revision codes, > there's a 0x3C400000, but that's different, that's why the chip > doesn't match any of the known HW ids. I really think the driver's > biting three bits more than it can chew here > Sorry, have no idea why I read it as 0x3C400000 instead of 0x34C00000. > > Would you show me the output of "CSR_READ_4(sc, RL_TXCFG)"? > > 0x37c00000 > OMG! This is completely new controller. > This is dmesg with the SVN driver - > > Jan 23 11:55:31 kernel: re0: <RealTek 8101E/8102E/8102EL PCIe > 10/100baseTX> port 0xec00-0xecff mem > 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on > pci3 > Jan 23 11:55:31 kernel: re0: Using 1 MSI messages > Jan 23 11:55:31 kernel: re0: Chip rev. 0x34800000 > Jan 23 11:55:31 kernel: re0: MAC rev. 0x00400000 > Jan 23 11:55:31 kernel: re0: Unknown H/W revision: 0x34c00000 > Jan 23 11:55:31 kernel: device_attach: re0 attach returned 6 > > dmesg after patch - > > Jan 23 12:58:04 kernel: re0: <RealTek 8101E/8102E/8102EL PCIe > 10/100baseTX> port 0xec00-0xecff mem > 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on > pci3 > Jan 23 12:58:04 kernel: re0: Using 1 MSI messages > Jan 23 12:58:04 kernel: re0: HWREV - 0x37c00000 > Jan 23 12:58:04 kernel: re0: Chip rev. 0x34800000 > Jan 23 12:58:04 kernel: re0: MAC rev. 0x00400000 > Jan 23 12:58:04 kernel: miibus0: <MII bus> on re0 > Jan 23 12:58:04 kernel: re0: Ethernet address: 90:fb:a6:29:80:cd > Jan 23 12:58:04 kernel: re0: [FILTER] > Jan 23 13:00:31 kernel: re0: link state changed to UP > Jan 23 13:00:40 dhclient: New Hostname (re0): > Jan 23 13:00:40 dhclient: New IP Address (re0): 192.168.1.103 > Jan 23 13:00:40 dhclient: New Subnet Mask (re0): 255.255.255.0 > Jan 23 13:00:40 dhclient: New Broadcast Address (re0): 255.255.255.255 > Jan 23 13:00:40 dhclient: New Routers (re0): 192.168.1.1 > > Just as a sidenote if it would help to understand the problem easier, > while debugging the issue I used as a reference the DragonflyBSD > driver - and more specifically this commit - > http://www.mail-archive.com/commits@crater.dragonflybsd.org/msg09347.html > Can't comment on these changes. sephe seems to have other ideas on handling RealTek's broken silicon revision naming. Anyway, would you try attached patch? I'm not entirely sure whether my patch is correct or not but I just added minimal support for the new controller(RTL8103E series). RTL8103E seems to have additional registers related with power control/WOL so I'm not sure the patch is enough to make suspend/resume/WOL work too. --45Z9DzgjV8m4Oswq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.RTL8103E.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 202820) +++ sys/dev/re/if_re.c (working copy) @@ -212,6 +212,7 @@ { RL_HWREV_8102E, RL_8169, "8102E"}, { RL_HWREV_8102EL, RL_8169, "8102EL"}, { RL_HWREV_8102EL_SPIN1, RL_8169, "8102EL"}, + { RL_HWREV_8103E, RL_8169, "8103E"}, { RL_HWREV_8168_SPIN2, RL_8169, "8168"}, { RL_HWREV_8168_SPIN3, RL_8169, "8168"}, { RL_HWREV_8168C, RL_8169, "8168C/8111C"}, @@ -1268,6 +1269,12 @@ RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_FASTETHER | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD; break; + case RL_HWREV_8103E: + sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_PHYWAKE | + RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | + RL_FLAG_FASTETHER | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | + RL_FLAG_MACSLEEP; + break; case RL_HWREV_8168_SPIN1: case RL_HWREV_8168_SPIN2: sc->rl_flags |= RL_FLAG_WOLRXENB; Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 202820) +++ sys/pci/if_rlreg.h (working copy) @@ -166,6 +166,7 @@ #define RL_HWREV_8100E 0x30800000 #define RL_HWREV_8101E 0x34000000 #define RL_HWREV_8102E 0x34800000 +#define RL_HWREV_8103E 0x34C00000 #define RL_HWREV_8168_SPIN2 0x38000000 #define RL_HWREV_8168_SPIN3 0x38400000 #define RL_HWREV_8168C 0x3C000000 --45Z9DzgjV8m4Oswq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100123234635.GH20753>