Date: Sat, 23 Jan 2010 15:42:55 +0200 From: Shteryana Shopova <syrinx@FreeBSD.org> To: yongari@freebsd.org Cc: freebsd-net@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: <61b573981001230542l59a9ab6y26514a213bfbdb67@mail.gmail.com> In-Reply-To: <201001221959.o0MJxnIs016854@freefall.freebsd.org> References: <201001221959.o0MJxnIs016854@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > Would you show me the output of "CSR_READ_4(sc, RL_TXCFG)"? 0x37c00000 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 > > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Fri Jan 22 19:57:19 UTC 2010 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=142974 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61b573981001230542l59a9ab6y26514a213bfbdb67>