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: > > >> > > >>r...@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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
