From minal@netvigator.com Thu Apr 11 01:47:28 2002 From: minal@netvigator.com (Minal Jain) Date: Thu Apr 11 00:47:28 2002 Subject: [realtek] problem with realtek rta 3000 Message-ID: <000801c1dee3$a3c00f20$d34e97d0@e1r3n4> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1DF26.B0CF2000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hye, Could you tell me where I could find the drivers for the Realtek RTA = 3000 sound card? minal@netvigator.com ------=_NextPart_000_0005_01C1DF26.B0CF2000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hye,
Could you tell me where I could find = the drivers=20 for the Realtek RTA 3000 sound card?
minal@netvigator.com
------=_NextPart_000_0005_01C1DF26.B0CF2000-- From vmaraujo@fitec.org.br Thu Apr 11 09:14:01 2002 From: vmaraujo@fitec.org.br (=?iso-8859-1?Q?Vald=EAnio_Miranda_de_Ara=FAjo?=) Date: Thu Apr 11 08:14:01 2002 Subject: [realtek] IP address Message-ID: <5F1EE827E9C3624282610E216BC502F347C9FB@bz0007dc26.fitec.org.br> Hi all, I have a question about definition of an IP address to RTL8019AS. Anybody has some information about that? Thanks. Valdenio Araujo. From becker@scyld.com Thu Apr 11 11:33:02 2002 From: becker@scyld.com (Donald Becker) Date: Thu Apr 11 10:33:02 2002 Subject: [realtek] IP address In-Reply-To: <5F1EE827E9C3624282610E216BC502F347C9FB@bz0007dc26.fitec.org.br> Message-ID: On Thu, 11 Apr 2002, Valdênio Miranda de Araújo wrote: > I have a question about definition of an IP address to RTL8019AS. > Anybody has some information about that? IP addresses and routing are unrelated to the device driver. You should read the documentation for your specific distribution for information on how to set up the IP address and routing information. This is something that distributions do differently. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From pp174754@zodiac.mimuw.edu.pl Thu Apr 11 12:50:29 2002 From: pp174754@zodiac.mimuw.edu.pl (Pawel) Date: Thu Apr 11 11:50:29 2002 Subject: [realtek] strange behaviour of rtl8139 card Message-ID: Hi I bought ethernet card with 8139 chip (digitus DN-1001) I have inserted it into pci slot and turn my linux on (red hat 7.1, kernel 2.4.3) and then compiled driver (rtl8139.c) from scyld site and inserted the driver into kernel. Whats the problem ? card was working properly but very slow. It lost about 60% IP datagrams. But thats not all. I restarted my computer and turn on windows 2000, then loaded driver from diskette and... the card was working perfectly. So I restarted my computer again, turn on the linux, inserted driver(the same as before) and ... card was working perfectly !?! isn't it strange? But when I removed the card from computer and later inserted it back. i had to start windows again, because of the same problem. these are registers before i started win2k: ./rtl8139-diag -a rtl8139-diag.c:v2.05 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xd800. The RealTek chip appears to be active, so some registers will not be read. To see all register values use the '-f' flag. RealTek chip registers at 0xd800 0x000: 3c440200 00000d04 80000000 00000000 0008a062 0008a062 0008a062 0008a062 0x020: 0f400000 0f400600 0f400c00 0f401200 0f340000 0d0a0000 d5b0d5a0 0000c07f 0x040: 74000600 0000d68e a1ef8fe0 00000000 006d1000 00000000 0088c110 00100000 0x060: 1100f00f 01e1782d 000141e1 00000000 00000004 000307c8 b0f243b9 8a36df43. No interrupt sources are pending. The chip configuration is 0x10 0x6d, MII full-duplex mode. and these are after, (and now card works ok) ./rtl8139-diag -a rtl8139-diag.c:v2.05 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xd800. The RealTek chip appears to be active, so some registers will not be read. To see all register values use the '-f' flag. RealTek chip registers at 0xd800 0x000: 3c440200 00000d04 80000000 00000000 0008a072 0008a042 0008a072 0008a042 0x020: 0f384000 0f384600 0f384c00 0f385200 0f340000 0d0a0000 39583948 0000c07f 0x040: 74000600 0000d68e 16727706 00000000 006d1000 00000000 0088c110 00100000 0x060: 1100f00f 01e1782d 000141e1 00000000 00000004 000307c8 b0f243b9 8a36df43. No interrupt sources are pending. The chip configuration is 0x10 0x6d, MII full-duplex mode. I'd like to know 1) change of which registers has solved the problem ? 2) there's a lot of registers in the rtl8139 specification (which i've downloaded from realtek). How to find the descriptions of registers which are printed by rtl8139-diag program ? 3) what do I have to do if i don't want to start windows after inserting this card to my computer.(how to configure it under linux) I'll be very grateful for help Pawe³ From g126@eee-fs4.bham.ac.ukt Sat Apr 13 16:31:01 2002 From: g126@eee-fs4.bham.ac.ukt (Peter Szmrecsanyi) Date: Sat Apr 13 15:31:01 2002 Subject: [realtek] Revisions of the RTL 8139 Message-ID: <000001c1e2ff$bdfae980$0401a8c0@petervaio> This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1E308.1FC0D820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've just go a hold of a NIC with an RTL8139D, my other one is a revision C, can anyone tell me if there are any major differences between these revisions? Do I need a more recent driver version to use it? Thanks for your time. Peter Szmrecsanyi. ------=_NextPart_000_0001_01C1E308.1FC0D820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve just go a hold of a NIC with an RTL8139D, = my other one is a revision C, can anyone tell me if there are any major differences between these revisions? Do I need a more recent driver = version to use it? Thanks for your time.

 

Peter Szmrecsanyi.

------=_NextPart_000_0001_01C1E308.1FC0D820-- From UNITEDDIS@aol.com Sat Apr 13 17:57:00 2002 From: UNITEDDIS@aol.com (UNITEDDIS@aol.com) Date: Sat Apr 13 16:57:00 2002 Subject: [realtek] REALTEK RTL 8139(A) Message-ID: <199.54a1d55.29e9f567@aol.com> ATTEMPTING TO INSTALL THE NETWORK CARD INTO A PIONEX 350 VINTAGE 1998. NEED A DRIVER. CAN ANYONE HELP. THANKS, BOBBY BLALOCK From cfowler@outpostsentinel.com Sat Apr 13 18:59:00 2002 From: cfowler@outpostsentinel.com (Chris Fowler) Date: Sat Apr 13 17:59:00 2002 Subject: [realtek] REALTEK RTL 8139(A) In-Reply-To: <199.54a1d55.29e9f567@aol.com> Message-ID: Need more info? What is a PHOENIX 350? What OS? Linux? What Kernel version of Linux. -----Original Message----- From: realtek-admin@scyld.com [mailto:realtek-admin@scyld.com]On Behalf Of UNITEDDIS@aol.com Sent: Saturday, April 13, 2002 4:56 PM To: realtek@scyld.com Subject: [realtek] REALTEK RTL 8139(A) ATTEMPTING TO INSTALL THE NETWORK CARD INTO A PIONEX 350 VINTAGE 1998. NEED A DRIVER. CAN ANYONE HELP. THANKS, BOBBY BLALOCK _______________________________________________ realtek mailing list realtek@scyld.com http://www.scyld.com/mailman/listinfo/realtek From leeyang77@hotmail.com Mon Apr 15 03:40:01 2002 From: leeyang77@hotmail.com (leeyang) Date: Mon Apr 15 02:40:01 2002 Subject: [realtek] interrupts error on ppc Message-ID: hi! I am trying to use rtl8139 NIC on Motorola Sandpoint evaluation board for MPC8245. But here are some problems I think related with interrupts. I put some my console msg below: ...... 8139too Fast Ethernet driver 0.9.24 eth0: RealTek RTL8139 Fast Ethernet at 0xbffe00, 00:e0:4c:5e:bf:25, IRQ 18 /*I compile the driver into the kernel.*/ ...... ...... # cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Class 0600: PCI device 1057:0006 (rev 18). Prefetchable 32 bit memory at 0x0 [0xffffffff]. Non-prefetchable 32 bit memory at 0x0 [0xfff]. Prefetchable 32 bit memory at 0x0 [0xffffffff]. Bus 0, device 11, function 0: Class 0601: PCI device 10ad:0565 (rev 16). IRQ 16. Bus 0, device 11, function 1: Class 0101: PCI device 10ad:0105 (rev 5). IRQ 16. Master Capable. Latency=128. Min Gnt=2.Max Lat=40. I/O at 0xbffff8 [0xbfffff]. I/O at 0xbffff4 [0xbffff7]. I/O at 0xbfffe8 [0xbfffef]. I/O at 0xbfffe4 [0xbfffe7]. I/O at 0xbfffd0 [0xbfffdf]. I/O at 0xbfffc0 [0xbfffcf]. Bus 0, device 13, function 0: Class 0200: PCI device 10ec:8139 (rev 16). IRQ 18. Master Capable. Latency=128. Min Gnt=32.Max Lat=64. I/O at 0xbffe00 [0xbffeff]. Non-prefetchable 32 bit memory at 0xbfffff00 [0xbfffffff]. ........ # ifconfig eth0 192.168.0.252 eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1. # eth0: Too much work at interrupt, IntrStatus=0x0001. eth0: Too much work at interrupt, IntrStatus=0x0001. eth0: Too much work at interrupt, IntrStatus=0x0001. eth0: Too much work at interrupt, IntrStatus=0x0001. /*and sometimes it says pci error*/ # eth0: PCI Bus error 2290. eth0: PCI Bus error 0290. #cat /proc/interrupts CPU0 2: 0 i8259 Edge 82c59 secondary cascade 4: 324 i8259 Edge serial 16: 0 OpenPIC Level 8259 cascade to EPIC 18: 55 OpenPIC Level eth0 BAD: 6 the numbers of interrupts (55) goes up but the bad number unchanged as time fly by. Could you explain the pop msg here and Why the card can not successfully work. BTW,I knew there are different between 8139too and rtl8139 driver, but I can not compile rtl8139.c in my cross compile enviroment. Best regards. From Anurag M Phadke" My hunch is there is some hardware problem. Most probably ur hardware is assigning some address to the card via BIOS whereas the same cannot be accessed by ur distro. I faced a similar problem trying to setup my realtek card on ibm thinkpad..... the eth0 interface was starting even before pcmcia services were initialized.... Try a different distro or try changing the /network/S.10 to /S.20 . -Regards Brainless On Mon, 15 Apr 2002 realtek-request@scyld.com wrote : >Send realtek mailing list submissions to > realtek@scyld.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.scyld.com/mailman/listinfo/realtek >or, via email, send a message with subject or body 'help' to > realtek-request@scyld.com > >You can reach the person managing the list at > realtek-admin@scyld.com > >When replying, please edit your Subject line so it is more >specific >than "Re: Contents of realtek digest..." > > >Today's Topics: > > 1. interrupts error on ppc (leeyang) > >--__--__-- > >Message: 1 > From: "leeyang" >To: >Date: Mon, 15 Apr 2002 14:37:35 +0800 >Subject: [realtek] interrupts error on ppc > >hi! > >I am trying to use rtl8139 NIC on Motorola >Sandpoint evaluation board for MPC8245. >But here are some problems I think related >with interrupts. > >I put some my console msg below: > >...... >8139too Fast Ethernet driver 0.9.24 >eth0: RealTek RTL8139 Fast Ethernet at 0xbffe00, >00:e0:4c:5e:bf:25, IRQ 18 >/*I compile the driver into the kernel.*/ >...... >...... ># cat /proc/pci >PCI devices found: > Bus 0, device 0, function 0: > Class 0600: PCI device 1057:0006 (rev 18). > Prefetchable 32 bit memory at 0x0 [0xffffffff]. > Non-prefetchable 32 bit memory at 0x0 [0xfff]. > Prefetchable 32 bit memory at 0x0 [0xffffffff]. > Bus 0, device 11, function 0: > Class 0601: PCI device 10ad:0565 (rev 16). > IRQ 16. > Bus 0, device 11, function 1: > Class 0101: PCI device 10ad:0105 (rev 5). > IRQ 16. > Master Capable. Latency=128. Min Gnt=2.Max Lat=40. > I/O at 0xbffff8 [0xbfffff]. > I/O at 0xbffff4 [0xbffff7]. > I/O at 0xbfffe8 [0xbfffef]. > I/O at 0xbfffe4 [0xbfffe7]. > I/O at 0xbfffd0 [0xbfffdf]. > I/O at 0xbfffc0 [0xbfffcf]. > Bus 0, device 13, function 0: > Class 0200: PCI device 10ec:8139 (rev 16). > IRQ 18. > Master Capable. Latency=128. Min Gnt=32.Max Lat=64. > I/O at 0xbffe00 [0xbffeff]. > Non-prefetchable 32 bit memory at 0xbfffff00 >[0xbfffffff]. >........ ># ifconfig eth0 192.168.0.252 >eth0: Setting 100mbps full-duplex based on auto-negotiated >partner ability >45e1. > ># eth0: Too much work at interrupt, IntrStatus=0x0001. >eth0: Too much work at interrupt, IntrStatus=0x0001. >eth0: Too much work at interrupt, IntrStatus=0x0001. >eth0: Too much work at interrupt, IntrStatus=0x0001. >/*and sometimes it says pci error*/ ># eth0: PCI Bus error 2290. >eth0: PCI Bus error 0290. >#cat /proc/interrupts > CPU0 > 2: 0 i8259 Edge 82c59 secondary cascade > 4: 324 i8259 Edge serial > 16: 0 OpenPIC Level 8259 cascade to EPIC > 18: 55 OpenPIC Level eth0 >BAD: 6 >the numbers of interrupts (55) goes up but the bad number >unchanged >as time fly by. > >Could you explain the pop msg here and Why the card can not >successfully work. >BTW,I knew there are different between 8139too and rtl8139 >driver, >but I can not compile rtl8139.c in my cross compile enviroment. > >Best regards. > > > >--__--__-- > >_______________________________________________ >realtek mailing list >realtek@scyld.com >http://www.scyld.com/mailman/listinfo/realtek > > >End of realtek Digest From loe@loe-online.de Mon Apr 15 18:04:01 2002 From: loe@loe-online.de (Siegfried =?iso-8859-1?q?L=F6schmann?=) Date: Mon Apr 15 17:04:01 2002 Subject: [realtek] Does rtl8139 work with kernel 2.4.18? Message-ID: <200204152209.00853.loe@loe-online.de> Hi all, I'm trying to update a diskless client, a tyan dual processor mb with 2 pentium 200 cpus and a Longshine rtl8139 network card to kernel 2.4.18. Since SuSe doesn't ship with Donalds driver anymore I first tried 8139too and it doesn't work. Apparently I need the ethernet driver built into the kernel and since I am not that familiar with hacking the kernel I had to do some reading until I managed to get the rtl8139 driver to compile. First problem: Compilation results in a naming conflict of "pci_find_capabilities". This is exported by pci.o. So I renamed all occurences to something else. After this building the kernel worked. Second problem: When booting the kernel now no adapter is recognised at all. Has anybody tried rtl8139 with 2.4.18 kernel. @Donald: is this supposed to work? Thanks in advance Siggi -- Siegfried Löschmann Schillerstr. 22 21423 Winsen fon: +49 4171 72415 mobile: +49 162 10 455 43 email: Siegfried.Loeschmann@loe-online.de web: www.loe-online.de From sbrauss@optronic.ch Tue Apr 16 11:41:02 2002 From: sbrauss@optronic.ch (Stephan Brauss) Date: Tue Apr 16 10:41:02 2002 Subject: [realtek] Bug in rtl8129_rx() & other problems Message-ID: <3CBC2BF3.DA77EC8C@optronic.ch> Hi all! I think I have found a bug in rtl8129_rx(): It is possible that dev_alloc_skb() is called with a negative argument, which causes my machine to crash. My system runs a heavy rtlinux task, that uses about 90% CPU time. Therefore, network interrupts are no more handled so quickly. Anyway, after many hours of debugging, I have changed the code like follows: } else { /* Malloc up new buffer, compatible with net-2e. */ /* Omit the four octet CRC from the length. */ struct sk_buff *skb; int pkt_size = rx_size - 4; + if(pkt_size<0) + { + printk(KERN_ERR"%s: Impossible packet length.\n",dev->name); + tp->stats.rx_dropped++; + rtl_hw_start(dev); + break; + } skb = dev_alloc_skb(pkt_size + 2); if (skb == NULL) { Maybe someone has a better solution? With the patch, the kernel no more crashes but I still get other messages: eth0: Abnormal interrupt, status 00000011. eth0: Abnormal interrupt, status 00000021. eth0: Abnormal interrupt, status 00000015. eth0: Abnormal interrupt, status 00000030. eth0: Abnormal interrupt, status 00000020. eth0: RTL8139 Interrupt line blocked, status 4. eth0: RTL8139 Interrupt line blocked, status 5. eth0: Transmit timeout, status 0d 0000 media 00. The "Abnormal interrupt" messages disappear when I increase RX_BUF_LEN_IDX to 3 (64K). I think they come from receive buffer overruns, because the rttask uses much CPU time. The "Interrupt line blocked" is strange. It is related to SMP stuff but my machine has only one CPU?! Donald: Could you please explain me the meaning of the "Check for bogusness" comment/code part? The "Transmit timeout" occurs from time to time. I applied the patch from Edgar Toering, but it does not help. It maybe turns up less frequently, but I'm not sure. Thanks Stephan From pp174754@zodiac.mimuw.edu.pl Tue Apr 16 14:48:01 2002 From: pp174754@zodiac.mimuw.edu.pl (Pawel) Date: Tue Apr 16 13:48:01 2002 Subject: [realtek] my card with 8139C does not work correctly Message-ID: hello I have problem with configuration of my ethernet card (digitus DN-1001 with rtl8139c chip) under linux. I tried rtl8139 and 8139too drivers with many kernels and card does not work as it should. it looses about 60% ip datagrams. Card is not physically broken because it works under windows. Cable is good because i have another ethernet card (Surecome EP-320XR with rtl8139c) and it works ok. So I think that the problem is with configuration. here are outputs from rtl8139-diag program: rtl8139-diag -aa: rtl8139-diag.c:v2.05 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xd800. The RealTek chip appears to be active, so some registers will not be read. To see all register values use the '-f' flag. RealTek chip registers at 0xd800 0x000: 3c440200 00000d04 80000000 00000000 0008a062 0008a062 0008a062 0008a062 0x020: 0f60a000 0f60a600 0f60ac00 0f60b200 0f5c0000 0d0a0000 a4dca4cc 0000c07f 0x040: 74000680 0000f78e e6c1610c 00000000 004d1000 00000000 0088c110 00100000 0x060: 1100f00f 01e1782d 000141e1 00000000 00000004 000307c8 b0f243b9 8a36df43. No interrupt sources are pending. The chip configuration is 0x10 0x4d, MII full-duplex mode. rtl8139-diag -ee: rtl8139-diag.c:v2.05 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xd800. Decoded EEPROM contents: PCI IDs -- Vendor 0x10ec, Device 0x8139. PCI Subsystem IDs -- Vendor 0x10ec, Device 0x8139. PCI timer settings -- minimum grant 32, maximum latency 64. General purpose pins -- direction 0xe1 value 0x12. Station Address 00:02:44:3C:04:0D. Configuration register 0/1 -- 0x4d / 0xc2. EEPROM active region checksum is 0812. EEPROM contents (64 words): 0x00: 8129 10ec 8139 10ec 8139 4020 e112 0200 0x08: 3c44 0d04 4d10 f7c2 8801 43b9 b0f2 071a 0x10: df43 8a36 df43 8a36 43b9 b0f2 1111 1111 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 0000 rtl8139-diag -m: rtl8139-diag.c:v2.05 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xd800. The RTL8139 does not use a MII transceiver. It does have internal MII-compatible registers: Basic mode control register 0x1100. Basic mode status register 0x782d. Autonegotiation Advertisement 0x01e1. Link Partner Ability register 0x41e1. Autonegotiation expansion 0x0001. Disconnects 0x0000. False carrier sense counter 0x0000. NWay test register 0x0004. Receive frame error count 0x0000. I compared these outputs with outputs when the surecom card was installed. these are outputs from rtl8139-diag(surecom EP-320XR with RTL8139C chip) rtl-8139-diag -m: --- exactly the same as above rtl-8139-diag -ee: --- very similar, the only differences are 1) PCI Subsystem IDs: Vendor 0x10bd, Device 0x0320 2) Hardware address rtl-8139-diad -aa: rtl8139-diag.c:v2.05 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xd800. The RealTek chip appears to be active, so some registers will not be read. To see all register values use the '-f' flag. RealTek chip registers at 0xd800 0x000: 38440200 000065c3 80000000 00000000 0008a072 0008a042 0008a072 0008a042 0x020: 0946e000 0946e600 0946ec00 0946f200 0f5c0000 0d0a0000 bee4bed4 0000c07f 0x040: 74000680 0000f78e fe8dbd8b 00000000 004d1000 00000000 0088c110 00100000 0x060: 1100f00f 01e1782d 000141e1 00000000 00000004 000107c8 b0f243b9 8a36df43. No interrupt sources are pending. The chip configuration is 0x10 0x4d, MII full-duplex mode. I don't know what to do. configuration of these two cards is very similar but one doesn't work. how to solve this problem ? Pawe³ From becker@scyld.com Tue Apr 16 16:23:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Apr 16 15:23:01 2002 Subject: [realtek] my card with 8139C does not work correctly In-Reply-To: Message-ID: On Tue, 16 Apr 2002, Pawel wrote: > I have problem with configuration of my ethernet card (digitus DN-1001 > with rtl8139c chip) under linux. I tried rtl8139 and 8139too drivers with > many kernels and card does not work as it should. it looses about 60% ip > datagrams. Card is not physically broken because it works under windows. > Cable is good because i have another ethernet card (Surecome > EP-320XR with rtl8139c) and it works ok. So I think that the problem is > with configuration. What driver version are you using? What is the detection message? What statistics are reported in /proc/net/dev after encountering a problem? Are you getting any messages from the driver? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue Apr 16 16:31:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Apr 16 15:31:01 2002 Subject: [realtek] Bug in rtl8129_rx() & other problems In-Reply-To: <3CBC2BF3.DA77EC8C@optronic.ch> Message-ID: On Tue, 16 Apr 2002, Stephan Brauss wrote: > I think I have found a bug in rtl8129_rx(): It is possible that dev_alloc_skb() > is called with a negative argument, which causes my machine to crash. What driver version are you using? What is the detection message? > My system runs a heavy rtlinux task, that uses about 90% CPU time. > Therefore, network interrupts are no more handled so quickly. I suspect that the problem you are seeing is related to this. > Anyway, after many hours of debugging, I have changed the code like follows: > + if(pkt_size<0) > + { > + printk(KERN_ERR"%s: Impossible packet length.\n",dev->name); Do you see this message? What is the Rx status when this occurs? > With the patch, the kernel no more crashes but I still get other messages: > eth0: Abnormal interrupt, status 00000011. Rx Overflow > eth0: Abnormal interrupt, status 00000021. RxUnderrun > eth0: RTL8139 Interrupt line blocked, status 4. > eth0: RTL8139 Interrupt line blocked, status 5. The R-T patches are obviously doing Bad Things. Your kernel is not servicing interrupts in a timely manne. This will cause packets to be dropped. It shouldn't crash the driver, but you should expectmany packets to be dropped. > eth0: Transmit timeout, status 0d 0000 media 00. More badness. > The "Abnormal interrupt" messages disappear when I increase > RX_BUF_LEN_IDX to 3 (64K). I think they come from receive buffer > overruns, because the rttask uses much CPU time. Yes. R-T shouldn't be used to completely consume the CPU, it is intended to be used to provide priority response to certain events. To do this it relies on having adequate average CPU to handle all pending task. > The "Interrupt line blocked" is strange... Could you please explain me > the meaning of the "Check for bogusness" comment/code part? It's intended to detect the case where the interrupt mapping is bogus, or becomes bogus due to an old APIC bug. SMP implies APIC, so that's the SMP tie-in. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From sbrauss@optronic.ch Wed Apr 17 09:57:00 2002 From: sbrauss@optronic.ch (Stephan Brauss) Date: Wed Apr 17 08:57:00 2002 Subject: [realtek] Bug in rtl8129_rx() & other problems References: Message-ID: <3CBD4453.4249317@optronic.ch> Hello! >> I think I have found a bug in rtl8129_rx(): It is possible that dev_alloc_skb() >> is called with a negative argument, which causes my machine to crash. > What driver version are you using? > What is the detection message? Sorry for not giving enough information. It tried with clean 1.13 and 1.17, with our without memory mapped operations (USE_MEM_OPS flag). Linux kernel is 2.2.19. >> My system runs a heavy rtlinux task, that uses about 90% CPU time. >> Therefore, network interrupts are no more handled so quickly. > I suspect that the problem you are seeing is related to this. Mainly yes. But not in all cases. Again, I didn't give enough information. Sorry... My system is rather slow, a 486 compatible running at 80MHz. Following messages turn up with a clean 2.2.19 linux kernel (without rtlinux patch) and clean 1.13/1.17 driver: eth0: RTL8139 Interrupt line blocked, status 1/4/5. eth0: Transmit timeout, status 0d 0000 media 00. The reason why I began debugging was the "transmit timeout" message I get from time to time. In this case, the network communications hangs for some seconds. Because I was the opinion that my problems could be related to the rather slow CPU, I wrote a simple rttask that uses up a certain amount of CPU time to make it even slower. With this constellation, the system crashed. > Anyway, after many hours of debugging, I have changed the code like follows: > + if(pkt_size<0) > + { > + printk(KERN_ERR"%s: Impossible packet length.\n",dev->name); > Do you see this message? What is the Rx status when this occurs? Yes, I get it from time to time when the rttask eats up 90% of CPU time. I agree that the reason why the crash can occur is that a receive buffer overrun occurs. In the problematic case, rx_size was always zero. In your driver, pkt_size is rx_size-4, therefore dev_alloc_skb() is called with a negative value which crashes my system. Well, I think it is a philosophical question if the kernel should rely on fast enough handling and a "correct" working network device, that does handle buffer overruns in a way that already received messages are not overwritten (which is maybe the reason for the problem?). Anyway, by detecting a pkt_size less than 0, the problem has gone and I think your driver would be more stable if it is guaranteed that dev_alloc_skb() isn't called with a unallowed negative value. >> eth0: RTL8139 Interrupt line blocked, status 4. >> eth0: RTL8139 Interrupt line blocked, status 5. > The R-T patches are obviously doing Bad Things. No, it also turns up with a clean 2.2.19. I retested this morning. >> eth0: Transmit timeout, status 0d 0000 media 00. > More badness. Yes, I know... Unfortunately, it is the reason why I started debugging. I still don't know how to get rid of it. It occurs seldom but it does. > relies on having adequate average CPU to handle all pending task. Oh, yes. I would be happy if our embedded system would have a faster CPU. But we have this system and (average) CPU load is not reaching 50% at the moment. I tried to trace the problem because I want the system to be "rock solid". I want avoid the system to die, if for example a rttask eats up CPU time for a short time. >> The "Interrupt line blocked" is strange... Could you please explain me >> the meaning of the "Check for bogusness" comment/code part? > It's intended to detect the case where the interrupt mapping is bogus, > or becomes bogus due to an old APIC bug. SMP implies APIC, so that's > the SMP tie-in. The "Interrupt line blocked" message is generated if the TxOK or RxOK bit is set in IntrStatus when the "Check for bogusness" code part is executed, yes? So the "problem" is that the rtl8129_timer() routine expects these bits not to be set? Why is it not allowed that these bits are set? Why is this check no more necessary for "newer" kernels? (>=20300). I maybe ask to much (stupid) questions, if you have no time to answer, don't. This morning I found another cause for "Abnormal interrupt" messages with 1.17: If I plug out the cable, I get: Abnormal interrupt, status 00000020. And if I plug it in again: Abnormal interrupt, status 00002020. And I made some more tests with a clean 2.2.19 kernel and 1.17 and got: Abnormal interrupt, status 00000021. And the network did not work anymore... After ifconfig eth0 down; ifconfig eth0 up it worked again... (Same problem that John Horton reported some time ago?) Thank you & best regards Stephan BTW: Maybe interesting for you: Realtek has a new datasheet on the web. Have you seen it? And do you have the rather old programming guide? - I have downloaded it some time ago. From qjmiao@yahoo.com Thu Apr 18 08:13:00 2002 From: qjmiao@yahoo.com (Miao Qingjun) Date: Thu Apr 18 07:13:00 2002 Subject: [realtek] Tx Status Questions (for RTL8139C) Message-ID: <20020418111201.76309.qmail@web12307.mail.yahoo.com> Hi, What are the actual meanings of bits and of Tx Status of Tx Desc??? And why they are set when Tx OK bit is set??? Thank you. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From becker@scyld.com Thu Apr 18 14:22:02 2002 From: becker@scyld.com (Donald Becker) Date: Thu Apr 18 13:22:02 2002 Subject: [realtek] Tx Status Questions (for RTL8139C) In-Reply-To: <20020418111201.76309.qmail@web12307.mail.yahoo.com> Message-ID: On Thu, 18 Apr 2002, Miao Qingjun wrote: > What are the actual meanings of bits Lost> and of Tx Status of Tx Desc??? > And why they are set when Tx OK bit is set??? They make sense if you understand the physical layer signaling of 100baseTx, and how it evolved from coax-based Ethernet with external tranceivers that provided "heartbeat" with a few invalid Rx bits at the end of each transmit attempt. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From ansgar.konermann@inf.tu-dresden.de Fri Apr 19 19:39:01 2002 From: ansgar.konermann@inf.tu-dresden.de (Ansgar W. Konermann) Date: Fri Apr 19 18:39:01 2002 Subject: [realtek] CardBus 8139too hangs when sending packets > 1472 bytes Message-ID: <3CC09C67.32655C@inf.tu-dresden.de> Hello Donald, hello everybody. I have a problem with the realtek 8139too.c driver. In combination with my system setup, it seems to hang the whole system whenever I try to send PING packets larger than 1472 bytes. Probably it also hangs the system with other applications than "ping", but I was not able to test that yet. I have no clue why the card works for small packets, but fails when the packets become larger. Problem description: I can send small ping packets up to a specific size and receive the answer from the peer. If the packets get larger, the system hangs. Since it's a laptop, neither the keyboard nor the soft-off power button work anymore. I have to remove the AC power cord and remove the battery to get the system back working... (in a rather rude way). When I issue: "ping -s 1472 192.168.10.3", i get this output: PING 192.168.10.3 (102.168.10.3): 1472 octets data 1480 octets from 192.168.10.3 icmp_seq=0 ttl=255 time=1.3 ms 1480 octets from 192.168.10.3 icmp_seq=1 ttl=255 time=1.2 ms 1480 octets from 192.168.10.3 icmp_seq=2 ttl=255 time=1.2 ms 1480 octets from 192.168.10.3 icmp_seq=3 ttl=255 time=1.2 ms ... So 1472 data bytes are still ok. But when I try to send one more byte of data, the following happens. "ping -s 1473 192.168.10.3" results in: PING 192.168.10.3 (102.168.10.3): 1573 octets data 1481 octets from 192.168.10.3 icmp_seq=0 ttl=255 time=1.5 ms [SYSTEM HANGS] One more interesting detail: the activity LED of the NIC still flashes irregularly (!! - this is clearly NOT 1 Hz as it's supposed to be when pinging). However, the activity LED at the hub's port which the NIC is connected to DOES NOT (strange, isn't it?) I'd be very glad if somebody could have a look at my system configuration (see below) and point me to the right direction. I've been trying for some days now. The card is working ok under MS Windows ME (in a different computer however). What could be wrong - what can I do to correct it and get it working? System configuration details: ============================= Contents: 1. NIC 2. Kernel 3. Driver 3. PCI bus (lspci) 1. NIC in use: ============== - "Unex MD010C" (10/100 Mbps Fast Ethernet PC Card) - card is connected to a 100 Mbps hub in half duplex mode <"cardctl status" output> Socket 0: 3.3V CardBus card function 0: [ready] Socket 1: no card <"cardctl ident" output> Socket 0: product info: "CardBus PC Card", "Fast Ethernet CardBus PC Card" manfid: 0x0000, 0x021b function: 6 (network) Socket 1: no product info available 2. Kernel ========= Kernel version is 2.4.18 - PCMCIA and CardBus support activated in kernel configuration - Power management turned OFF (neither AGP nor ACPI) - Kernel configuration file available upon request. 3. Driver ========= Driver name and version: 8139too.c, Version 0.9.24 After inserting the NIC into a pcmcia slot, the system loads the 8139too driver and logs the following messages: Apr 19 23:58:19 eagle kernel: cs: cb_alloc(bus 1): vendor 0x10ec, device 0x8139 Apr 19 23:58:19 eagle kernel: PCI: Enabling device 01:00.0 (0000 -> 0003) Apr 19 23:58:19 eagle kernel: 8139too Fast Ethernet driver 0.9.24 Apr 19 23:58:19 eagle kernel: PCI: Setting latency timer of device 01:00.0 to 64 Apr 19 23:58:19 eagle kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xc483b000, 00:10:60:5a:00:12, IRQ 11 Apr 19 23:58:19 eagle kernel: [...] [...] Apr 19 23:58:20 eagle kernel: cs: IO port probe 0x0c00-0x0cff: clean. Apr 19 23:58:20 eagle kernel: cs: IO port probe 0x0800-0x08ff: excluding 0x800-0x807 Apr 19 23:58:20 eagle kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x330-0x337 0x388-0x38f 0x398-0x39f 0x4d0-0x4d7 Apr 19 23:58:20 eagle kernel: cs: IO port probe 0x0a00-0x0aff: clean. Apr 19 23:58:20 eagle kernel: eth0: Setting half-duplex based on auto-negotiated partner ability 0000. Apr 19 23:59:04 eagle login[151]: ROOT LOGIN on `tty1' [...] 4. PCI bus ========== <"lspci" output> 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- (32-bit, prefetchable) [size=256M] 00:06.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 01) (prog-if 00 [VGA]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 00:0a.1 CardBus bridge: O2 Micro, Inc. 6832 (rev 02) Subsystem: O2 Micro, Inc. 6832 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10) Subsystem: Billionton Systems Inc: Unknown device 0200 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- -- Best regards, Ansgar W. Konermann --- Hello, I am a message footer. ------------------------------------- From girishkm@jataayusoft.com Tue Apr 23 07:21:00 2002 From: girishkm@jataayusoft.com (Girish Kamath) Date: Tue Apr 23 06:21:00 2002 Subject: [realtek] rtl8139 on 2.0.32 kernel Message-ID: <3CC53637.6050502@jataayusoft.com> Hi All, I am trying to have RTL 8139 card on RH 5.0 running kernel 2.0.32 I need only this version of the kernel for very specific reason. Linux did not install the driver during installation, so i had to manually download and install the driver. I successfully compiled the driver and did a insmod pci-scan insmod rtl8139 My ETH0 interface is up and i can do a self ping. But Iam *not* able to ping other linux boxes on the net. If i install RH 6.2 on the same server, the card is recognized and networking works well. Can some one pls give me pointers to solve this issue. Thanks in advance, Girish From becker@scyld.com Tue Apr 23 12:49:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Apr 23 11:49:01 2002 Subject: [realtek] rtl8139 on 2.0.32 kernel In-Reply-To: <3CC53637.6050502@jataayusoft.com> Message-ID: On Tue, 23 Apr 2002, Girish Kamath wrote: > I am trying to have RTL 8139 card on RH 5.0 running kernel 2.0.32 > I need only this version of the kernel for very specific reason. > Linux did not install the driver during installation, so i had to > manually download > and install the driver. > I successfully compiled the driver and did a > insmod pci-scan > insmod rtl8139 > My ETH0 interface is up and i can do a self ping. But Iam *not* able to ping > other linux boxes on the net. This is likely a routing problem, but you haven't provided enough information for anyone to tell. What is the driver version? What is the detection message? Are there any other driver messages? What does /proc/net/dev report about packets and errors? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From girishkm@jataayusoft.com Thu Apr 25 03:30:01 2002 From: girishkm@jataayusoft.com (Girish Kamath) Date: Thu Apr 25 02:30:01 2002 Subject: [realtek] rtl8139 on 2.0.32 kernel References: Message-ID: <3CC7A35C.7090209@jataayusoft.com> --------------060004080202010109030708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Thanks for ur response, The routing table is fine in my linux box. The second linux box iam trying to ping on the same LAN. The rtl8139 driver version is 1.16a LSMOD shows me both pci-scan and rtl8139 loaded and this is the output of cat /proc/net/dev Inter-| Receive | Transmit face |packets errs drop fifo frame|packets errs drop fifo colls carrier lo: 20 0 0 0 0 20 0 0 0 0 0 eth0: 0 0 0 0 0 6 0 0 0 0 0 eth1: 0 0 0 0 0 0 0 0 0 0 0 Interstingly, I have only one interface ETH0 configured on my system, but this shows me ETH1 as well. If I do /sbin/ifconfig -a i can see only LO and ETH0 Am i missing anything.? Thanks, Girish Donald Becker wrote: >On Tue, 23 Apr 2002, Girish Kamath wrote: > >>I am trying to have RTL 8139 card on RH 5.0 running kernel 2.0.32 >>I need only this version of the kernel for very specific reason. >>Linux did not install the driver during installation, so i had to >>manually download >>and install the driver. >>I successfully compiled the driver and did a >>insmod pci-scan >>insmod rtl8139 >>My ETH0 interface is up and i can do a self ping. But Iam *not* able to ping >>other linux boxes on the net. >> > >This is likely a routing problem, but you haven't provided enough >information for anyone to tell. > >What is the driver version? >What is the detection message? >Are there any other driver messages? >What does /proc/net/dev report about packets and errors? > --------------060004080202010109030708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

Thanks for ur response,
The routing table is fine in my linux box. The second linux box iam trying to
ping on the same  LAN.
The rtl8139 driver version is 1.16a

LSMOD shows me both
pci-scan and rtl8139 loaded

and this is the output of cat /proc/net/dev

Inter-|   Receive                  |  Transmit
 face |packets errs drop fifo frame|packets errs drop fifo colls carrier
    lo:     20    0    0    0    0       20    0    0    0     0    0
  eth0:      0    0    0    0    0        6    0    0    0     0    0
  eth1:      0    0    0    0    0        0    0    0    0     0    0

Interstingly, I have only one interface ETH0 configured on my system, but this shows
me ETH1 as well. If I do
/sbin/ifconfig -a
i can see only LO and ETH0

Am i missing anything.?

Thanks,
Girish

Donald Becker wrote:
On Tue, 23 Apr 2002, Girish Kamath wrote:

I am trying to have RTL 8139 card on RH 5.0 running kernel 2.0.32
I need only this version of the kernel for very specific reason.
Linux did not install the driver during installation, so i had to
manually download
and install the driver.
I successfully compiled the driver and did a
insmod pci-scan
insmod rtl8139
My ETH0 interface is up and i can do a self ping. But Iam *not* able to ping
other linux boxes on the net.

This is likely a routing problem, but you haven't provided enough
information for anyone to tell.

What is the driver version?
What is the detection message?
Are there any other driver messages?
What does /proc/net/dev report about packets and errors?


--------------060004080202010109030708-- From froese@gmx.de Thu Apr 25 18:00:01 2002 From: froese@gmx.de (Edgar Toernig) Date: Thu Apr 25 17:00:01 2002 Subject: [realtek] Patch for TX timeout Message-ID: <3CC86DCB.A1CEA7B2@gmx.de> Hi, I wrote about this already in Febrary. Because the rtl8129_start_xmit routine still contains the bug here's a patch to fix it "the crude way" (ok for UP, don't know for SMP). --- rtl8139-116a.c +++ rtl8139.c @@ -962,6 +962,26 @@ rtl8129_start_xmit(struct sk_buff *skb, outl(virt_to_bus(tp->tx_buf[entry]), ioaddr + TxAddr0 + entry*4); } else outl(virt_to_bus(skb->data), ioaddr + TxAddr0 + entry*4); + +#if 1 /* ET: */ + { + unsigned long flags; + + save_flags(flags); + cli(); + + outl(tp->tx_flag | (skb->len >= ETH_ZLEN ? skb->len : ETH_ZLEN), + ioaddr + TxStatus0 + entry*4); + + if (++tp->cur_tx - tp->dirty_tx >= NUM_TX_DESC) + set_bit(0, &tp->tx_full); + else + netif_unpause_tx_queue(dev); + + restore_flags(flags); + } +#else /* original */ + /* Note: the chip doesn't have auto-pad! */ outl(tp->tx_flag | (skb->len >= ETH_ZLEN ? skb->len : ETH_ZLEN), ioaddr + TxStatus0 + entry*4); @@ -978,6 +998,7 @@ rtl8129_start_xmit(struct sk_buff *skb, netif_stop_tx_queue(dev); } else netif_unpause_tx_queue(dev); +#endif dev->trans_start = jiffies; if (debug > 4) For a description see my posting from Febrary. I still have one problem. Though I thought it's a bug in one of the cards I noticed that someone else reported the same problem: 2 rtl8139, both 2.0.32 kernel with 1.16a driver, directly connected with crossover cable. With 10mbit every- thing works fine. With 100mbit, transfer in on direction is fine, too. But the other direction will crawl: one card gets looots of RX-errors. Turning the cable (a la: if it's faulty in one direction errors will occure on the other side) doesn't change anything. Still rx-errors (frame errors iirc) on the same card. Any idea? Ciao, ET. From becker@scyld.com Thu Apr 25 22:52:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Apr 25 21:52:01 2002 Subject: [realtek] rtl8139 on 2.0.32 kernel In-Reply-To: <3CC7A35C.7090209@jataayusoft.com> Message-ID: On Thu, 25 Apr 2002, Girish Kamath wrote: > Thanks for ur response, > The routing table is fine in my linux box. The second linux box iam > trying to > ping on the same LAN. > The rtl8139 driver version is 1.16a What is the detection message? > eth0: 0 0 0 0 0 6 0 0 0 0 0 > eth1: 0 0 0 0 0 0 0 0 0 0 0 > > Interstingly, I have only one interface ETH0 configured on my system, > but this shows > me ETH1 as well. If I do > /sbin/ifconfig -a > i can see only LO and ETH0 You have two driver trying to support the single device. What is the detection message? > >>I am trying to have RTL 8139 card on RH 5.0 running kernel 2.0.32 > >>I successfully compiled the driver and did a > >>insmod pci-scan > >>insmod rtl8139 ... > >This is likely a routing problem, but you haven't provided enough > >information for anyone to tell. > > > >What is the driver version? > >What is the detection message? > >Are there any other driver messages? > >What does /proc/net/dev report about packets and errors? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From girishkm@jataayusoft.com Fri Apr 26 04:00:00 2002 From: girishkm@jataayusoft.com (Girish Kamath) Date: Fri Apr 26 03:00:00 2002 Subject: [realtek] rtl8139 on 2.0.32 kernel References: Message-ID: <3CC8FBFE.8000309@jataayusoft.com> --------------070809060303000801050303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi >>Thanks for ur response, >>The routing table is fine in my linux box. The second linux box iam >>trying to >>ping on the same LAN. >>The rtl8139 driver version is 1.16a >> > >What is the detection message? > Can you pls let me know what is detection message ? how do i get it ? >> eth0: 0 0 0 0 0 6 0 0 0 0 0 >> eth1: 0 0 0 0 0 0 0 0 0 0 0 >> >>Interstingly, I have only one interface ETH0 configured on my system, >>but this shows >>me ETH1 as well. If I do >>/sbin/ifconfig -a >>i can see only LO and ETH0 >> > >You have two driver trying to support the single device. >What is the detection message? > Again, how do i check for detection message ? Regards, Girish Kamath --------------070809060303000801050303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi 
Thanks for ur response,
The routing table is fine in my linux box. The second linux box iam
trying to
ping on the same  LAN.
The rtl8139 driver version is 1.16a

What is the detection message?
Can you pls let me know what is detection message ? how do i get it ?
  eth0:      0    0    0    0    0        6    0    0    0     0    0
  eth1:      0    0    0    0    0        0    0    0    0     0    0

Interstingly, I have only one interface ETH0 configured on my system,
but this shows
me ETH1 as well. If I do
/sbin/ifconfig -a
i can see only LO and ETH0

You have two driver trying to support the single device.
What is the detection message?
Again, how do i check for detection message ?
Regards,
Girish Kamath
--------------070809060303000801050303-- From becker@scyld.com Fri Apr 26 13:00:04 2002 From: becker@scyld.com (Donald Becker) Date: Fri Apr 26 12:00:04 2002 Subject: [realtek] rtl8139 on 2.0.32 kernel In-Reply-To: <3CC8FBFE.8000309@jataayusoft.com> Message-ID: On Fri, 26 Apr 2002, Girish Kamath wrote: > >>Thanks for ur response, > >>The routing table is fine in my linux box. The second linux box iam > >>trying to > >>ping on the same LAN. > >>The rtl8139 driver version is 1.16a > >> > > > >What is the detection message? > > > Can you pls let me know what is detection message ? how do i get it ? The message from the driver when the card is found. Use 'dmesg' or 'cat /var/log/messages'. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From vrivero@teleline.es Sat Apr 27 15:06:03 2002 From: vrivero@teleline.es (Victor Rivero) Date: Sat Apr 27 14:06:03 2002 Subject: [realtek] 8139 autonegotiation problem Message-ID: <200204271804.g3RI4QD21052@blueraja.scyld.com> Hello , first of all sorry for my english (i'm from spain), i write you because i have a serious problem with my ethernet adapter, i have an ovislink RTL8139-B, i'm connected to a hub at 10baseT, i've had always problems to boot correctly the card because (i think) it couldn't do the autonegotiation, but i solved it forcing the media to 10baseT (with mii-diag or mii-tool). The serious problem began when since kernel 2.4.5 or 2.4.4 (i don't know it exactly), i couldn't solve the problem forcing with mii-diag, so it says that there is no link. I'm sure that my cables are perfect, so i don't know what can i do, if you can help me it would be great. I tried with kernel 2.4.18 (I heard that it has new support for ovislink cards) but it didn't do anything different ( the card lights off and the hub sometimes but not always blinks). thank you for reading my problem, i hope you could me answer something. (i'm not subscribed to the list) Victor Rivero vrivero@teleline.es here is some of my information (Debian , 2.4.18): victor:~# lsmod Module Size Used by Not tainted emu10k1 50592 1 ac97_codec 9504 0 [emu10k1] agpgart 12384 0 (unused) 8139too 13920 1 mii 1040 0 [8139too] victor:~# cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 196). Prefetchable 32 bit memory at 0xd0000000 [0xd3ffffff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 35). Bus 0, device 7, function 1: IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 16). Master Capable. Latency=32. I/O at 0xd000 [0xd00f]. Bus 0, device 7, function 2: USB Controller: VIA Technologies, Inc. UHCI USB (rev 17). IRQ 10. Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 7, function 3: Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 48). Bus 0, device 18, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 5. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0xd800 [0xd8ff]. Non-prefetchable 32 bit memory at 0xd8000000 [0xd80000ff]. Bus 0, device 19, function 0: Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 8). IRQ 10. Master Capable. Latency=32. Min Gnt=2.Max Lat=20. I/O at 0xdc00 [0xdc1f]. Bus 0, device 19, function 1: Input device controller: Creative Labs SB Live! (rev 8). Master Capable. Latency=32. I/O at 0xe000 [0xe007]. Bus 1, device 0, function 0: VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 21). IRQ 11. Master Capable. Latency=32. Min Gnt=5.Max Lat=1. Non-prefetchable 32 bit memory at 0xd4000000 [0xd4ffffff]. Prefetchable 32 bit memory at 0xd6000000 [0xd7ffffff]. victor:~# mii-tool eth0: 10 Mbit, half duplex, no link victor:~# rtl8139-diag -mmaaavvvee rtl8139-diag.c:v2.03 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xd800. The RealTek chip appears to be active, so some registers will not be read. To see all register values use the '-f' flag. RealTek chip registers at 0xd800 0x000: f026c000 00003a31 80000000 00000000 0008a0e7 0008a0e7 0008a06e 0008a0e7 0x020: 07be6000 07be6600 07be6c00 07be7200 065e0000 0d000000 0000fff0 0000c07f 0x040: 78000680 0000f78e 2c61179a 00000000 008d1001 00000000 0088c114 00100000 0x060: 2100f00f 01e17809 00000000 00000000 00000000 000f73c0 58fab388 ad38d843. No interrupt sources are pending. The chip configuration is 0x10 0x8d, MII half-duplex mode. EEPROM size test returned 6, 0x204a4 / 0x2. Parsing the EEPROM of a RealTek chip: PCI IDs -- Vendor 0x10ec, Device 0x8139, Subsystem 0x10ec. PCI timer settings -- minimum grant 32, maximum latency 64. General purpose pins -- direction 0xc1 value 0x23. Station Address 00:C0:26:F0:31:3A. Configuration register 0/1 -- 0x8d / 0xc2. EEPROM active region checksum is 0901. EEPROM contents: 8129 10ec 8139 10ec 8139 4020 c123 c000 f026 3a31 8d10 07c2 8801 b388 58fa 8708 d843 ad38 d843 ad38 d843 ad38 d843 ad38 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 The word-wide EEPROM checksum is 0x5756. Would write new Default Media entry 0x0000 to offset 6, the current value is 0xc123. The RTL8139 does not use a MII transceiver. It does have internal MII-compatible registers: Basic mode control register 0x7809. Basic mode status register 0x2100. Autonegotiation Advertisement 0x01e1. Link Partner Ability register 0x0000. Autonegotiation expansion 0x0000. Disconnects 0x0000. False carrier sense counter 0x0000. NWay test register 0x0000. Receive frame error count 0x0000. MII PHY #-1 transceiver registers:1111111111100000-> 11111111111111111111 MII read of -1:0 -> 0000. 00001111111111100001-> 51111111111111111111 MII read of -1:1 -> 0000. 00001111111111100010-> 11111111111111111111 MII read of -1:2 -> 0000. 00001111111111100011-> 51111111111111111111 MII read of -1:3 -> 0000. 00001111111111100100-> 11111111111111111111 MII read of -1:4 -> 0000. 00001111111111100101-> 51111111111111111111 MII read of -1:5 -> 0000. 00001111111111100110-> 11111111111111111111 MII read of -1:6 -> 0000. 00001111111111100111-> 51111111111111111111 MII read of -1:7 -> 0000. 00001111111111101000-> 11111111111111111111 MII read of -1:8 -> 0000. 00001111111111101001-> 51111111111111111111 MII read of -1:9 -> 0000. 00001111111111101010-> 11111111111111111111 MII read of -1:10 -> 0000. 00001111111111101011-> 51111111111111111111 MII read of -1:11 -> 0000. 00001111111111101100-> 11111111111111111111 MII read of -1:12 -> 0000. 00001111111111101101-> 51111111111111111111 MII read of -1:13 -> 0000. 00001111111111101110-> 11111111111111111111 MII read of -1:14 -> 0000. 00001111111111101111-> 51111111111111111111 MII read of -1:15 -> 0000. 00001111111111110000-> 11111111111111111111 MII read of -1:16 -> 0000. 00001111111111110001-> 51111111111111111111 MII read of -1:17 -> 0000. 00001111111111110010-> 11111111111111111111 MII read of -1:18 -> 0000. 00001111111111110011-> 51111111111111111111 MII read of -1:19 -> 0000. 00001111111111110100-> 11111111111111111111 MII read of -1:20 -> 0000. 00001111111111110101-> 51111111111111111111 MII read of -1:21 -> 0000. 00001111111111110110-> 11111111111111111111 MII read of -1:22 -> 0000. 00001111111111110111-> 51111111111111111111 MII read of -1:23 -> 0000. 00001111111111111000-> 11111111111111111111 MII read of -1:24 -> 0000. 00001111111111111001-> 51111111111111111111 MII read of -1:25 -> 0000. 00001111111111111010-> 11111111111111111111 MII read of -1:26 -> 0000. 00001111111111111011-> 51111111111111111111 MII read of -1:27 -> 0000. 00001111111111111100-> 11111111111111111111 MII read of -1:28 -> 0000. 00001111111111111101-> 51111111111111111111 MII read of -1:29 -> 0000. 00001111111111111110-> 11111111111111111111 MII read of -1:30 -> 0000. 00001111111111111111-> 51111111111111111111 MII read of -1:31 -> 0000. 0000. Basic mode control register 0x0000: Auto-negotiation disabled! Speed fixed at 10 mbps, half-duplex. 1111111111100001-> 51111111111111111111 MII read of -1:1 -> 0000. Basic mode status register 0x0000 ... 0000. Link status: not established. Capable of . Unable to perform Auto-negotiation, negotiation not complete. This transceiver has no vendor identification. I'm advertising 0000: Advertising no additional info pages. Using an unknown (non 802.3) encapsulation. Link partner capability is 0000:. Negotiation did not complete. From schuenzel@t-online.de Sat Apr 27 18:04:01 2002 From: schuenzel@t-online.de (schuenzel) Date: Sat Apr 27 17:04:01 2002 Subject: [realtek] Realtek RT 8139 (A) Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1EE3F.B1EE0140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hallo, ich habe mir heute einen Laptop bei Vobis gekauft und eine Installations -CD für die installierte Hardware mitbekommen. Leider ist der im Betreff erwähnte Treiber für die Netzwerkkarte nicht dabei. Bitte schicken Sie mir diesen fehlenden Treiber per E-Mail. Vielen Dank. O.-E. Schünzel ------=_NextPart_000_0000_01C1EE3F.B1EE0140 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgcVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHBAAbABcAAwAAAAYAGAEB A5AGAFwFAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAFAAAAFJlYWx0ZWsgUlQgODEzOSAoQSkAAgFxAAEAAAAWAAAAAcHuLuzjcybeDloyEdaPtgAw hDz8RQAAAgEdDAEAAAAbAAAAU01UUDpTQ0hVRU5aRUxAVC1PTkxJTkUuREUAAAsAAQ4AAAAAQAAG DgDateku7sEBAgEKDgEAAAAYAAAAAAAAAEvCeTRlEtYRj7YAMIQ8/EXCgAAACwAfDgEAAAACAQkQ AQAAAH4BAAB6AQAAwQEAAExaRnVgTg1/AwAKAHJjcGcxMjUWMgD4C2BuDhAwMzFPAfcCpAPjAgBj aArAc7BldDAgBxMCgH0KgZJ2CJB3awuAZDQMYM5jAFALAwu1IEgHQAkATiwKogqADeBoIBDwYhBl IG1pBcBoZXUadBUAZQuACfAgTGERBTBvcCAU8GkgVgRvYgQAIGdla2EydQGAIHUSgBWzIEnHAIAB kBPwYXRpAiAEIIAtQ0QgZlwnEND1BcBkCJAgC4AYYwiRFZH7E9ALIHcKwBUCAlAXQANw6QeAbi4U NEwVwASBGgDHGGAZwBzSbSBCETAJcBMBIBWwcncZcGU0aOsCMBUAVAlwaRTwBcAZadEHwHR6dwSQ axdQGqKvAwAQ4B0hFOFpHCVCG4CrFZEE8GgN4GsV8VMZ4Q8VIhnRESADoGZlaGwvCfABAAOgHvZw HNFFLWpNC3BsHCVWCJAkMSAKRABwaxwlTy4tRc4uBgAQ4BlybnomUBQ0BRHhACkAAAALAAGACCAG AAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAA AwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALZ0AQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABU hQAAAQAAAAQAAAA5LjAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAA AADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9 gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAA AAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAAS8J5NGUS1hGP tgAwhDz8RQIB+g8BAAAAEAAAAEvCeTRlEtYRj7YAMIQ8/EUCAfsPAQAAAIEAAAAAAAAAOKG7EAXl EBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5ET1dT XExvY2FsIFNldHRpbmdzXEFud2VuZHVuZ3NkYXRlblxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29r LnBzdAAAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAA1AAAAPE5HQkJJUExHRUxQQ1BOQUlKSkZI S0VMTkNBQUEuc2NodWVuemVsQHQtb25saW5lLmRlPgAAAAADAAYQjDOh1AMABxDzAAAAAwAQEAAA AAADABEQAAAAAB4ACBABAAAAZQAAAEhBTExPLElDSEhBQkVNSVJIRVVURUVJTkVOTEFQVE9QQkVJ Vk9CSVNHRUtBVUZUVU5ERUlORUlOU1RBTExBVElPTlMtQ0RG/FJESUVJTlNUQUxMSUVSVEVIQVJE V0FSRU1JVEIAAAAAVSQ= ------=_NextPart_000_0000_01C1EE3F.B1EE0140-- From ansgar.konermann@inf.tu-dresden.de Sat Apr 27 18:22:00 2002 From: ansgar.konermann@inf.tu-dresden.de (Ansgar W. Konermann) Date: Sat Apr 27 17:22:00 2002 Subject: [realtek] Realtek RT 8139 (A) References: Message-ID: <3CCB15C4.3C5E89D@inf.tu-dresden.de> schuenzel wrote: > > Hallo, > ich habe mir heute einen Laptop bei Vobis gekauft und eine Installations -CD > für die installierte Hardware mitbekommen. > Leider ist der im Betreff erwähnte Treiber für die Netzwerkkarte nicht > dabei. > Bitte schicken Sie mir diesen fehlenden Treiber per E-Mail. > Vielen Dank. > O.-E. Schünzel (some words in German to the poster) Soweit ich weiß, dreht sich auf dieser Mailingliste alles um Treiber für das Betriebssystem LINUX und die Sprache dieser Liste ist ENGLISCH. Im übrigen bin ich der Meinung, dass in erster Linie die Firma VOBIS für den Support der von ihr verkaufen Notebooks zuständig ist, nicht aber die Gemeinschaft von Open-Source- Entwicklern. Ich bezweifle, dass die Firma VOBIS Notebooks mit vor- installiertem Linux ausliefert. Daher ist hier der falsche Ort, um nach Treibern zu fragen. Nebenbei bemerkt: der Treiber für eine Realtek 8139 (A) Karte ist bei den neueren Windows-Versionen direkt beim Betriebssystem dabei. For the others: Mr Schuenzel asked to send him the drivers for the card mentioned in the subject line. He bought a notebook at a german retail store recently and is missing this particular driver from the installation cd. Since it is *very* unlikely (I did not check for myself, but I know those "VOBIS" stores) that the mentioned retail store sells notebooks preinstalled with linux, I told him that he was presumably looking in the wrong place to find his drivers. For recent Windows (tm) operating systems, the driver for RTL 8139 based NICs was included with the operating system itself. Best regards, Ansgar From ensys_ecos1@HotPOP.com Tue Apr 30 13:44:01 2002 From: ensys_ecos1@HotPOP.com (ensys_ecos1) Date: Tue Apr 30 12:44:01 2002 Subject: [realtek] Writing Device drivers Message-ID: <003801c1f038$e1cae590$0264a8c0@server> HI! I want ot write a device driver for realtek LAN card (RTL 8139)for ecos. can u pls suggest from where should I start and how to proceed. regards Nitin Mahajan