FreeBSD 7.1 Breaks re and rl Network Interface Drivers

[Jung-uk Kim]

On Friday 16 January 2009 11:47 pm, Pyun YongHyeon wrote:
> On Tue, Jan 13, 2009 at 03:53:59PM +0100, Sascha Holzleiter wrote:
>  > Jung-uk Kim wrote:
>  > >On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote:
>  > >>Hi,
>  > >>
>  > >>i see similar problems with a re card:
>  > >>
>  > >>re0 at pci0:4:7:0:	class=0x020000 card=0x816710ec chip=0x816710ec
>  > >>rev=0x10 hdr=0x00
>  > >>     vendor     = 'Realtek Semiconductor'
>  > >>     device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
>  > >>     class      = network
>  > >>     subclass   = ethernet
>  > >>
>  > >>After upgrading to 7.1-RELEASE (and also STABLE) the NIC
>  > >> doesn't seem to receive any frames. I can see the DHCP
>  > >> Requests on the DHCP Server but the DHCPOFFERS are never seen
>  > >> by the client with the re0 device. After setting promiscious
>  > >> mode on the interface (i.e. by tcpdump -ni re0) the interface
>  > >> begins to work fine.
>  > >>
>  > >>I've attached a complete dmesg output, but i think the
>  > >> detection works fine, here the short version:
>  > >>
>  > >>re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
>  > >>0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0
>  > >> on pci4 re0: Chip rev. 0x18000000
>  > >>re0: MAC rev. 0x00000000
>  > >>miibus0: <MII bus> on re0
>  > >>rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on
>  > >> miibus0 rgephy0:  10baseT, 10baseT-FDX, 100baseTX,
>  > >> 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
>  > >>re0: Ethernet address: 00:1a:92:35:29:fa
>  > >>re0: [FILTER]
>  > >
>  > >Please revert SVN r180519 (or CVS r1.95.2.22) and try again:
>  > >
>  > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.di
>  > >ff?r1=1.95.2.21;r2=1.95.2.22
>  >
>  > Thanks! This fixed my problem. I now have DHCP and a running
>  > network interface again with a 7.1-STABLE and the reverted
>  > r180519 changes. If you need to test another version for the
>  > changes in r180519 let me know and i'll test them on this
>  > machine.
>
> It seems that RTL8169SC does not like memory mapping. Instead of
> using io mapping for all revisions, how about attached patch?

I found something interesting.  I have another RTL8169SC that works 
perfectly fine without the patch.  The hardware revision is 
0x18000000.  After reading Linux driver (drivers/net/r8169c), I 
realised they use different masks for hardware revisions.  With their 
logic, non-working chip seems to be 0x98000000 (8110SCe) while 
working chip seems to be 0x18000000 (8110SCd) with 0xfc800000.  
FYI...

Jung-uk Kim