i386/142974: [patch][net][if_re] Teach the if_re driver to properly recognize hardware revisions with non-zero MAC rev. bits

[Shteryana Shopova]

Hi,

On Fri, Jan 22, 2010 at 9:59 PM,  <yongari at 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
>