From humesj@ti.com Mon Nov 1 10:26:54 1999 Date: Mon Nov 1 10:26:54 1999 From: humesj humesj@ti.com Subject: Realtek 8139/ 10Mbps This is a multi-part message in MIME format. ------=_NextPart_000_002F_01BF244B.28C26980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0030_01BF244B.28C6FD60" ------=_NextPart_001_0030_01BF244B.28C6FD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit How do I set the Realtek 8139 in redhat linux to force it to 10 Mb vice 100 Mb. 100 is not compatible with my router.... ------=_NextPart_001_0030_01BF244B.28C6FD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How do I set = the Realtek=20 8139 in redhat linux to force it to 10 Mb vice 100 = Mb.
 
100 is not = compatible with=20 my router....
------=_NextPart_001_0030_01BF244B.28C6FD60-- ------=_NextPart_000_002F_01BF244B.28C26980 Content-Type: image/gif; name="Chess.gif" Content-Transfer-Encoding: base64 Content-ID: <540492415@01111999-23e4> R0lGODlhQAZlAPcAAP////7+/v39/fz8/Pv7+/r6+vn5+fj4+Pf39/b29vX19fT09PPz8/Ly8vHx 8fDw8O/v7+7u7u3t7ezs7Ovr6+rq6unp6ejo6Ofn5+bm5uXl5ePj4+Li4uHh4eDg4N/f397e3t3d 3dzc3Nvb29ra2tnZ2djY2NfX19bW1tXV1dTU1NPT09LS0tHR0dDQ0M/Pz87Ozs3NzczMzMvLy8rK ysnJycjIyMfHx8bGxsXFxcTExMPDw8LCwsHBwcDAwL+/v76+vr29vby8vLu7u7q6urm5ubi4uLe3 t7a2trW1tbS0tLOzs7KysrGxsbCwsK+vr66urq2traysrKurq6qqqqmpqaioqKenp6ampqWlpaSk pKOjo6KioqGhoaCgoJ+fn56enp2dnZycnJubm5qampmZmZiYmJeXl5aWlpWVlZSUlJOTk5KSkpGR kZCQkI+Pj46Ojo2NjYyMjIuLi4qKiomJiYiIiIeHh4aGhoWFhYSEhIODg4KCgoGBgYCAgH9/f35+ fgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAQAZlAEAI/wBvXPlC sKDBgwgTKlxY8M2XK0duvDjxoaLFixgzntj44sWNHz+OPLky8Mybk3dS3nlz5ckPihAQIABAs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2hz nvD4YyRBk29S/pl75wzDu3ffnIH4YyLFjIADC764cW3HGxgSx5yZtrHjx5AjS55MubLly5gza97M ubPnz6BDmxVc2PDHkCNLmlQ5909dvAb18vU7uLZtwaJz697Nu7fv38CDCx9OvLjx48jT3rZd+jBI kQO/wGVN1+TeI303Lt9+O7n37+DDi/8fT768+fPo06tHzr194OYeP8L+csR9+/X48+vfz7+///8A BijggETZZyBpJ8yn4Bc/2EfggxBGKOGEFFZo4YUY9nfghhhttOCHsN1gUYYklmjiiSimqOKKLJqI 1xN/cYggiDTCNhEGEMTU4o489ujjj0AGKeSQT9Wo0BExbuehkUwm5NILH2AgE5FUVmnllVhmqeWW wzVpJJIVLenlmE9GOSWXaKap5ppstunmmziNSaZbq90xl0NywlamlIzB6eefgAYq6KCElpdnk3p9 8URENzT60RHQvYWSna3hyeSeZxaq6aacdurpp6BidSiTsmFH22CFHXbaE25JN2lrf1j/ehCmfYZq 66245qrrrmy+EFJJKtk1KkOlZpfkgRSlGl9I0EUH0g0n4Jgpr9RWa+212GYLoEUcsYUaSdLVSalr wpJ6nbEyuqftuuy26+678Oqm5AfKettsuHHJVZ1CxZ6a7nbxBizwwAQXbDBU/wIG32n3SpcQmAkv d/DEFFds8cXrRmygmDQ2+C/GIIcs8sgkr6mxfRwPa5DHuJXs8sswxyxzhQbBeDJzCaoM4rQz9+zz z0AHLVyNNqebss56RgQTz0I37fTTUEftFdIFQfxezlQrSKvUXHft9ddg/5S1gh9FNzZDW4et9tps ty3z2bAl+lBBZ0w3bqw6p+323nz3/+33u3Dj1a92YXbbKLOt2g2rrC/2ZWatf0cu+eSUF3pD4MSe 6y93yh4uEp12q3RHS47zWfnpqKeuOpYeHVES5rFpTjiyhq8K+kknLep4jpCv7vvvwAdPIVsj1dna a1kPfuy/nT8KqV+K9S789NRXb315HHnuumr5jou8nMrffPUJMpV//fnop68+cB12/lxq+FJHbo3h i9/y+vjnr//+lN1WL8OJE9fxyrWQ+tkPMPxLoAIXyECtbIxehrEXq94iwH01RHbLO2BFGsjBDnrw g0HRWPPeF526TcpSppqdBi8Cwha68IUMXGGysgfACS6kPivcIAx3yMMeUi+HCOoIiP9wqDEfGvGI SJQcEGvzAjmxzEBJjKIUp9i1Jc4IaU+sDRW3yMUuxsyKV4PdF0SUES+a8YxoPFjRwMgtrInxIGmM oxzniC2FrFGDR3vjF6TFNDr68Y+A9NOC7sg8N+qRID+AVpR0FMhGOvKRWfKS1VBmyEOSDkrSgqQm N8nJFulskqiqpB4v+QHedfKUqEzlhDBHRMKIUo9lWowqZ0nLWubnkFVrIi5rtjtG2vKXwAzmcXZZ ENS4inGBi2UfhcnMZjqTM8RMCFzyVamxxdKXz8ymNrcJmWh+IVGsgtTnSjipcSHzUrtbJjfXyc52 iiqaxZIIR9aivcSVs5o0uqb03Mn/z376MyneHBy9NJKqepKze/hEWzr3+c+GOvShcYInBpVUO9TY E6F34iWUTAnRjnoUor56wi4NyDkImsZ54DqmSlhiqsd99KUwdWfrrgAXAsKNpBuqaFsCeIZFKVJK MQ2qUJ9JPFdR6nvJm2jERggpVl2hUZiU5VCnStVZrsWY36SmBXWG06XW7iMViZ46q0rWstIxe1g1 ofz+YNMxdfVmzeGd+cxK17r60aQSBJda9TU/tyrVijNhqF0HS9gpttFwJOTeWtu6oLdqsLCQjSwX Fea+bymWr0idj2MPKNnOetaItflfYuPHV7Zq9q9L/KxqVwtCzkUQgCWsYF/5hVog/7L2trhN4MZe m9i6yda0B9ms/XJL3OKij0NMjRRpvScs4YrPuNCNLvASJlrLqlR0d5DObFRoW+l697uTg2tBYUtB 3NUMWhl8LHjXy9624bFbyxonQ0Cp3vba975SW+LCnIeXLD4XvwAOMNDYiNfDLKiVRRSwghfsMgIP FIK6BJF/OcTgClv4Yg4+rJcmrK4Le/jDAstwGw/F4e6A+MQo1paIC6ezEgcmxTCO8a5WDMGxuXhE Ms6xjjtF4zxi8X47DrKQ/dTjV46NjDgespKXnKYiE1NETI6ylK9EEELq18iwE+yUt8zlEyHEygf0 sRgXo+Uum/nMELpLer3qzUVKFf/NcI4zgeYDZqNhGXPy5KOc98xn/oCozrv1pktEpOc+G/rQhjIS oCnqTb4srcyIjrSkeyMn+m4nwrskHUVMN+lOe/o3w1o0Qb2pqNKN9dOoTvVlqGbp9pFab6qOtawr A7dWixl2pMzkrHfNa8eIcZK3ht2esNnrYhv7K7hE0loaDetjO/vZVvHmEQRtakhD+9rYJoo3P1I8 Sw7b2tkOt7h1Iu0JriZWjKXat8fN7naLLZokKcmr6HK2XJ/a3fgOtzfrZhATYtQ16q52vgee74Da pSWsuqhWAX6oXBOb4BDHtsEVhR2QIO6g8jtnPkv38Ih7/NgG54tEOhJf5YYuoSBosje4P85yT4fc VH5pjkEl9W+NKxST9265zjv98r5MpH00vDjNMw4bh69850jnc883B3R6PsqpQ+erzUsd1aMn/epo Xjp3FYbXmV/XnAdROdbHznOJbnfN43M6SKB+XddkVOxkj/uhAwIAOw== ------=_NextPart_000_002F_01BF244B.28C26980-- | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Mon Nov 1 10:41:23 1999 Date: Mon Nov 1 10:41:23 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: Realtek 8139/ 10Mbps > How do I set the Realtek 8139 in redhat linux to force it to 10 Mb vice 100 > Mb. > > 100 is not compatible with my router.... ------- Forwarded Message Date: Mon Nov 1 10:41:23 1999 From: Donald Becker To: pascal duchemin Cc: linux-realtek@beowulf.gsfc.nasa.gov Subject: Re: RTL8139 and 10/100 Base T On Wed, 27 Oct 1999, pascal duchemin wrote: > I would like to know if it's possible to force the drivers of the realtek > 8139 to 10 BASET instead of 100 Base T ? Read http://cesdis.gsfc.nasa.gov/linux/diag/index.html Do mii-diag -F 10baseT or mii-diag -A 10baseT > I tried : ifconfig eth0 media 10baset I don't know who implemented that "feature" of ifconfig, but they were pretty clueless about the issues. It was simple back when there was only 10base2, AUI, and 10baseT. But now "10baseT" might mean "autonegotiate, advertising both 10baseT-half-duplex and 10baseT-full-duplex" "autonegotiate, advertising only 10baseT-HDX" "use the 10baseT transceiver, disabling autonegotiation" "use the 10baseT transceiver, ignoring lack of link beat" With most newer chips the 10baseT transceiver might be internal to the chip, or implemented as part of the external MII transceiver. This doubles the number of potential means of "10baseT". Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. ------- End of Forwarded Message Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From kiko@radiumsystems.com.br Mon Nov 1 11:18:35 1999 Date: Mon Nov 1 11:18:35 1999 From: Christian Robottom Reis kiko@radiumsystems.com.br Subject: RTL8139 loosing connectivity; stock 2.2.13 Please note I'm sorry if this is a "try the cesdis driver" kind of question. I'm having sporadic failure using an rtl8139 with stock 2.2.13 on two boxes here. It's strange - it seems like it's loosing link but the lights on my hub stay on. It's just as if the cable were working - except it isn't. I've switched cables to no avail and am really down to either a broken card or a broken driver. Is there a known problem with lost connectivity? Unplugging the card and plugging it in again IIRC fixes the problem. rmmod'ing the driver and modprobing it back definitely fixes the problem. Just don't forget to fix the routes when you do that. 8) k | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Mon Nov 1 11:38:52 1999 Date: Mon Nov 1 11:38:52 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: RTL8139 loosing connectivity; stock 2.2.13 > I'm having sporadic failure using an rtl8139 with stock 2.2.13 on two > boxes here. Join the club. I curse the day I bought all of those cheap rtl8139 cards... My 3c905's never have such problems, nor any of my 10Mbps cards. > Is there a known problem with lost connectivity? Unplugging the card and > plugging it in again IIRC fixes the problem. I've never seen this one, then again, I'm not sure if I tried that... > rmmod'ing the driver and > modprobing it back definitely fixes the problem. Usually a simple "ifconfig down; ifconfig up" works too. Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From kiko@radiumsystems.com.br Mon Nov 1 12:02:01 1999 Date: Mon Nov 1 12:02:01 1999 From: Christian Robottom Reis kiko@radiumsystems.com.br Subject: RTL8139 loosing connectivity; stock 2.2.13 On Tue, 2 Nov 1999 sharkey@ale.physics.sunysb.edu wrote: > > I'm having sporadic failure using an rtl8139 with stock 2.2.13 on two > > boxes here. > > Join the club. I curse the day I bought all of those cheap rtl8139 cards... Does the cesdis driver differ significantly from the distributed driver? And is running the diagnostic any help at all? > My 3c905's never have such problems, nor any of my 10Mbps cards. Aye, we have vortexes on most boxes and they work fine. My NE2000s work well, surprisingly. > > rmmod'ing the driver and > > modprobing it back definitely fixes the problem. > > Usually a simple "ifconfig down; ifconfig up" works too. And we keep the routes. Better idea :) k | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From drabiger@zpr.uni-koeln.de Tue Nov 2 08:27:43 1999 Date: Tue Nov 2 08:27:43 1999 From: Dirk Raebiger drabiger@zpr.uni-koeln.de Subject: Duplex mode Hi there! I'm using v1.08a of rtl8139 together with linux kernel 2.2.13. The network administrator at the institute here says that my machine (gollum) sends in full-duplex mode. This is also what the led of the card says (full duplex). The card (Mercy with RealTek 8139) can be configured by a DOS tool and its EEPROM is set to 10MBIT/half duplex, how it should be. The 'rtl8139-diag' says the following: ================================================= gollum:/scratch/dr/tmp# ./rtl8139-diag -e rtl8139-diag.c:v1.01 4/30/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a RealTek RTL8139 adapter at 0xc000. 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 0xe1 value 0x00. Station Address 00:E0:7D:02:9D:4A. Configuration register 0/1 -- 0x5c / 0xc2. EEPROM active region checksum is 09c2. gollum:/scratch/dr/tmp# ./rtl8139-diag -a rtl8139-diag.c:v1.01 4/30/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a RealTek RTL8139 adapter at 0xc000. 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 0xc000 0x000: 027de000 00004a9d 80000000 00000000 0008050a 9008a50a 9008a5ea 000825ea 0x020: 0f95c000 0f95c600 0f95cc00 0f95d200 0f920000 0d0a0000 6a506a40 0000c07f 0x040: 73000400 00009c0e ea1240d6 00000000 002c10c6 00000000 0000c108 00100000 0x060: 0000600e 05e1780d 00000000 00000000 00000000 000f77c0 38fa8388 ad38de43. No interrupt sources are pending. The chip configuration is 0x10 0x2c, MII half-duplex mode. ================================================= ifconfig reports errors, matching the Cisco analysis of our network administrator: ================================================= gollum:/scratch/dr/tmp# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:33 errors:0 dropped:0 overruns:0 frame:0 TX packets:33 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0 eth0 Link encap:Ethernet HWaddr 00:E0:7D:02:9D:4A inet addr:134.95.11.226 Bcast:134.95.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:42987 errors:1 dropped:0 overruns:0 frame:0 TX packets:42063 errors:0 dropped:0 overruns:0 carrier:0 Collisions:6716 Interrupt:11 Base address:0xc000 ================================================= Can anyone help me, why the card thinks it's in full duplex? What can I do? Thanks alot, Dirk -- Homepage at http://www.raebiger.net/ PGP5.0i key at http://www.zpr.Uni-Koeln.DE/~drabiger/pgp.html Vote against SPAM! http://www.politik-digital.de/spam/ | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From becker@cesdis.gsfc.nasa.gov Tue Nov 2 09:34:10 1999 Date: Tue Nov 2 09:34:10 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: Duplex mode On Tue, 2 Nov 1999, Dirk Raebiger wrote: > I'm using v1.08a of rtl8139 together with linux kernel 2.2.13. The network > administrator at the institute here says that my machine (gollum) sends in > full-duplex mode. This is also what the led of the card says (full duplex). Incorrect duplex is not a typical problem for a rtl8139. > The card (Mercy with RealTek 8139) can be configured by a DOS tool and its > EEPROM is set to 10MBIT/half duplex, how it should be. Hmmm, the Linux driver doesn't know about a field defined for the default media type type. > The 'rtl8139-diag' says the following: ... > The chip configuration is 0x10 0x2c, MII half-duplex mode. Then the chip is in half duplex mode. > Parsing the EEPROM of a RealTek chip: .. > Configuration register 0/1 -- 0x5c / 0xc2. .. > RealTek chip registers at 0xc000 > 0x060: 0000600e 05e1780d 00000000 00000000 00000000 000f77c0 38fa8388 ad38de43. Run 'mii-diag' to see the current transceiver status. > ifconfig reports errors, matching the Cisco analysis of our network > administrator: ... > eth0 Link encap:Ethernet HWaddr 00:E0:7D:02:9D:4A > RX packets:42987 errors:1 dropped:0 overruns:0 frame:0 > TX packets:42063 errors:0 dropped:0 overruns:0 carrier:0 > Collisions:6716 Please report the contents of /proc/net/dev rather than the summarized output of 'ifconfig'. I would hardly call this reporting errors -- a single Rx error could be from many sources. You are getting collisions which is a certain indication that you are *not* in full duplex mode. > Can anyone help me, why the card thinks it's in full duplex? What can I > do? There is no indication that the card is in full duplex mode. None at all. Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From drabiger@zpr.uni-koeln.de Tue Nov 2 09:48:08 1999 Date: Tue Nov 2 09:48:08 1999 From: Dirk Raebiger drabiger@zpr.uni-koeln.de Subject: Duplex mode Hi there! Am Tue, 02 Nov 1999 schrieb Donald Becker: >On Tue, 2 Nov 1999, Dirk Raebiger wrote: > >> I'm using v1.08a of rtl8139 together with linux kernel 2.2.13. The network >> administrator at the institute here says that my machine (gollum) sends in >> full-duplex mode. This is also what the led of the card says (full duplex). > >Incorrect duplex is not a typical problem for a rtl8139. May be right, I am no wizard on that topic. Can you tell me a apropriate place for this? >>> The chip configuration is 0x10 0x2c, MII half-duplex mode. >Then the chip is in half duplex mode. But the card's led says, "full duplex"! >Please report the contents of /proc/net/dev rather than the summarized >output of 'ifconfig'. Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 24492 423 0 0 0 0 0 0 24492 423 0 0 0 0 0 0 eth0:248148029 483518 1 0 0 0 0 0 176119795 437044 0 0 0 103195 0 0 b >I would hardly call this reporting errors -- a single Rx error could be from >many sources. What can I do? >You are getting collisions which is a certain indication that you are *not* >in full duplex mode. Where can I read about collisions and their sources? What do you think is it then? >There is no indication that the card is in full duplex mode. >None at all. What about the card's led? Dirk -- Homepage at http://www.raebiger.net/ PGP5.0i key at http://www.zpr.Uni-Koeln.DE/~drabiger/pgp.html Vote against SPAM! http://www.politik-digital.de/spam/ | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From becker@cesdis.gsfc.nasa.gov Tue Nov 2 10:01:40 1999 Date: Tue Nov 2 10:01:40 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: Duplex mode On Tue, 2 Nov 1999, Dirk Raebiger wrote: > Am Tue, 02 Nov 1999 schrieb Donald Becker: > >On Tue, 2 Nov 1999, Dirk Raebiger wrote: > > > >> I'm using v1.08a of rtl8139 together with linux kernel 2.2.13. The network > >> administrator at the institute here says that my machine (gollum) sends in > >> full-duplex mode. This is also what the led of the card says (full duplex). > > > >Incorrect duplex is not a typical problem for a rtl8139. > > May be right, I am no wizard on that topic. Can you tell me a apropriate > place for this? This mailing list is the correct place to report rtl8139 problems. > >>> The chip configuration is 0x10 0x2c, MII half-duplex mode. > >Then the chip is in half duplex mode. > > But the card's led says, "full duplex"! The LED might be labeled full duplex. But the LED output pins may be programmed to indicate several status conditions. I'll check out the datasheet later (I don't have a copy right now) to see what the default output conditions are. > >Please report the contents of /proc/net/dev rather than the summarized > >output of 'ifconfig'. > > Inter-| Receive | Transmit > face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed > eth0:248148029 483518 1 0 0 0 0 0 176119795 437044 0 0 0 103195 0 0 > b ... > >You are getting collisions which is a certain indication that you are *not* > >in full duplex mode. > > Where can I read about collisions and their sources? Any description of Ethernet. Ethernet is half duplex, and collisions are normal and expected. A lack of collisions would indicate that you might be full duplex mode, which uses Ethernet frame format but removes the contention-access aspect. Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Tue Nov 2 10:20:41 1999 Date: Tue Nov 2 10:20:41 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: Duplex mode > Where can I read about collisions and their sources? Collisions occur when two hosts on a network send a packet on the same wire at the same time. The data gets trashed and both hosts need to resend it. This is a normal event for ethernet and nothing to worry about, so long as it doesn't happen *too* often. By definition, in order for a host to be in full duplex mode, it has to be able to send and receive at the same time. If it's receiving, that means that another host must be sending, which means that two hosts will be sending at the same time. That's a guaranteed collision unless you're not sending and receiving on the same wire, i.e. you are directly connected to another host via a cross-over cable or you are connected to a switching hub, and if that's the case, collisions are impossible. That's why, if you're in duplex mode, you can't get collisions. Got it? Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From -axis-@hanmail.net Sat Nov 6 03:31:26 1999 Date: Sat Nov 6 03:31:26 1999 From: äÁ¾±Ç -axis-@hanmail.net Subject: I want smc1211tx linux driver please send me driver ... ================================================== -'_'- ================================================== No. 1 ¿ì¸® ÀÎÅͳÝ, ´ÙÀ½ Æò»ý ¾²´Â ¹«·á E-mail ÁÖ¼Ò ÇѸÞÀÏ³Ý http://www.daum.net | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From raarts@netland.nl Tue Nov 9 05:41:03 1999 Date: Tue Nov 9 05:41:03 1999 From: Ron Arts raarts@netland.nl Subject: Couldn't allocate a 65535 byte receive ring, 2.0.38 lock ups I have a system with 7 PCI cards, with 7 realtek 8139 cards in them. Occasionally I get the above error at boot. Also the system totally locks up after a couple of hours. Other hardware is negligible: Celeron 433, Adaptec 1542, and 32Mb RAM. Thats it. Kernel version is 2.0.38. This is what we standardize upon. Ron Arts On a side note, does anyone have advice on an alternative card? 3c905 perhaps, or Intel EtherExpress, these are readily available here. | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From Join2save@aol.com Tue Nov 9 11:30:53 1999 Date: Tue Nov 9 11:30:53 1999 From: Join2save@aol.com Join2save@aol.com Subject: Minor problem.... Hello, my name is Steve Huckabee and I am the Computer Systems Admin for a company called Passport America. We have a small Ethernet set-up in our office and are useing Realtek RTL8029 PCI Ethernet card to connect, my problem is that they have lost the driver disks for the card. We are using Windows 95 opperating system on the PC that I am currently having problems with. If you have this driver handy, please e-mail it to me at "join2save@aol.com" or call me at 1-800-681-6810 and let me know where I can download these drivers at. I appreciate any assistance that you can give me. Steve Huckabee | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Wed Nov 10 03:06:56 1999 Date: Wed Nov 10 03:06:56 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: Minor problem.... > Hello, my name is Steve Huckabee Hi, Steve! > and I am the Computer Systems Admin for a > company called Passport America. That's nice. > We have a small Ethernet set-up in our > office and are useing Realtek RTL8029 PCI Ethernet card to connect, my > problem is that they have lost the driver disks for the card. No problem! You've come to the right place. You can download a driver from this page: http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html > We are using Windows 95 opperating system Oh, that is a problem. Windows 95 is obsolete and is not supported by the driver mentioned above. Why don't you upgrade your OS to something better? If you wish to purchase a CD-ROM with a new operating system, you may get a copy, for very little cost, from www.cheapbytes.com. I recommend this upgrade package: http://cart.cheapbytes.com/cgi-bin/cart/0070010409 It also contains the driver for the 8029 ethernet card right on the disk, so there's no need to need to download it separately! If you have a fast connection to the internet, you can also download the upgrade from ftp://ftp.us.debian.org/debian. Instructions for installing the upgrade are available here: ftp://ftp.debian.org/debian/dists/stable/main/disks-i386/current/install.html Enjoy, Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From servettazj@marseille.fnclcc.fr Fri Nov 12 02:39:20 1999 Date: Fri Nov 12 02:39:20 1999 From: Jerome Revet-Servettaz servettazj@marseille.fnclcc.fr Subject: Message with the last realtek driver Hello i had installed the realtek 8139 v 1.08 driver on my linux box. The old version was v 0.99B. When the system start, i've got this message in the logfile. Nov 12 08:21:11 mail kernel: The PCI BIOS has not enabled the device at 0/112! Updating PCI command 0003->0007. The network seems run well but can you explain me what this message means ? thanks you in advance ---------------------------------------------- Jérôme REVET-SERVETTAZ Institut PAOLI CALMETTES D.S.I.O 232 Bd de Sainte Marguerite 13009 Marseille Tél:04 91 22 34 68 Fax:04 91 22 35 54 http://www.fnclcc.fr/-gen/clcc/marseill/marseil.htm ---------------------------------------------- | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From pcg@gospelcom.net Fri Nov 12 08:53:13 1999 Date: Fri Nov 12 08:53:13 1999 From: Peter Green pcg@gospelcom.net Subject: two questions The first question I have is easy: is this list archived anywhere? I'd like to be able to thumb through the archives... The second is not so easy: I have a couple of Realtek knockoffs with an MPX EN-5038 chipset. They are detected just fine, the linklight comes on when connected (both at the NIC and the switch), and pings light up the activity light. HOWEVER, the pings don't actually succeed. Worse, no errors seem to occur. While pinging from this interface, ifconfig shows the TX packets incrementing and the remote end's RX packets incrementing. RX on the sending end and TX on the receiving end are not incrementing. On one occasion, the kernel complained about something like incorrect frame size. I didn't write it down because I thought SURELY it would repeat. It hasn't, and I've rebooted. :( I'm relatively sure I've got the network setup right. Currently, I'm using the stock RH6 kernel w/ version 1.04 of the rtl8139.c driver. This behavior also shows up using version 1.08; I haven't tried 1.08a (since it didn't look all that different/helpful for my particular situation). Any thoughts on this bizarre problem? (If not, I'm returning these silly cards...) /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Fri Nov 12 09:07:53 1999 Date: Fri Nov 12 09:07:53 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: two questions > The first question I have is easy: is this list archived anywhere? I'd like > to be able to thumb through the archives... Not that I know of, but that's hardly definitive... > The second is not so easy: I have a couple of Realtek knockoffs with an MPX > EN-5038 chipset. They are detected just fine, the linklight comes on when > connected (both at the NIC and the switch), and pings light up the activity > light. HOWEVER, the pings don't actually succeed. Worse, no errors seem to > occur. While pinging from this interface, ifconfig shows the TX packets > incrementing and the remote end's RX packets incrementing. RX on the sending > end and TX on the receiving end are not incrementing. This could be a hardware problem. Is the situation symmetric? I.E., if you ping from host A to host B, A's TX increments, B's RX increments, but nothing else, but, if you ping from B to A, does B's TX increment then? If not, I'd suspect faulty cabling. Swap the cables the machines are using and see if the behavior asymmetry follows the cables. Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From pcg@gospelcom.net Fri Nov 12 09:14:54 1999 Date: Fri Nov 12 09:14:54 1999 From: Peter Green pcg@gospelcom.net Subject: two questions On Fri, Nov 12, 1999 at 11:07:35PM +0900, sharkey@ale.physics.sunysb.edu wrote: Thanks for the reply, > > The second is not so easy: I have a couple of Realtek knockoffs with an MPX > > EN-5038 chipset. They are detected just fine, the linklight comes on when > > connected (both at the NIC and the switch), and pings light up the activity > > light. HOWEVER, the pings don't actually succeed. Worse, no errors seem to > > occur. While pinging from this interface, ifconfig shows the TX packets > > incrementing and the remote end's RX packets incrementing. RX on the sending > > end and TX on the receiving end are not incrementing. > > This could be a hardware problem. I understand. However, I've tried three different (identical chipset) cards. > Is the situation symmetric? I.E., if you ping from host A to host B, A's > TX increments, B's RX increments, but nothing else, but, if you ping from > B to A, does B's TX increment then? It is completely symmetric: A->B ==> A.TX++, B.RX++ B->A ==> B.TX++, A.RX++ > If not, I'd suspect faulty cabling. Swap the cables the machines are using > and see if the behavior asymmetry follows the cables. For the question of cabling, I've tried connecting two machines with a crossover cable (using two distinct cables). I've tried connecting the machine with the MPX cards to a 3com 10/100 switch and accessing it from other hosts on that switch (again, using two distinct cables). BTW, the error I mentioned in my last post came back up. It's: eth0: Oversized Ethernet frame, status 2900a50d! eth0: Oversized Ethernet frame, status fb9fcca8! /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Fri Nov 12 09:29:13 1999 Date: Fri Nov 12 09:29:13 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: two questions > I understand. However, I've tried three different (identical chipset) cards. FWIW, the Realtek 8139 is the most problematical chip I have ever used. I also have three of these cards, and swapping cards never solves a problem. I've never observed the type of problem you're suggesting, but I'm almost ready to trash all of mine, too. My cards only have problems once or twice a month, but, that's still too often for me. > It is completely symmetric: > > A->B ==> A.TX++, B.RX++ > B->A ==> B.TX++, A.RX++ Hmm. Not likely cabling then. Have you tried using "tcpdump" to view traffic on the line? These machines must have some sort of two way communication before a ping can actually be sent. At a minimum you would need the sender to first issue an arp request and receive an arp reply before a ping could be sent. You should be able to see all of that with tcpdump. Does the hardware address of B get into A's arp cache when you issue a ping? I don't really have a clue what your problem is, I'm just poking for more info that might possibly shed some light on the issue. Donald might just know everything. He frequently seems to. Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From henrikso@ifi.uio.no Fri Nov 12 09:35:35 1999 Date: Fri Nov 12 09:35:35 1999 From: Henrik Solgaard henrikso@ifi.uio.no Subject: two questions On Fri, 12 Nov 1999, Peter Green wrote: > The first question I have is easy: is this list archived anywhere? I'd like > to be able to thumb through the archives... You can find it here: http://beowulf.gsfc.nasa.gov/listarchives/linux-realtek/ Henrik Solgaard | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From aellison@mcmail.com Fri Nov 12 09:51:31 1999 Date: Fri Nov 12 09:51:31 1999 From: Anthony Ellison aellison@mcmail.com Subject: rtl8139 Driver This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF2D1D.73C735C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am new to Linux, in fact new to Unix I get to the point, just = purchased a PC installed suse linux 6.2=20 download network driver rtl8139.c for me network card.=20 Q/ What is the correct compile command for compiling this c code once compiled how do I install it or is there a binary file I can use i.e. my P.C. spec if a clone IBM = Pentium I 330 Many Thanks in advance you help will be much appreciated Anthony Ellison ------=_NextPart_000_0005_01BF2D1D.73C735C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I am new to Linux, in fact new to Unix I get to the = point,=20 just purchased a PC installed suse linux 6.2
download network driver rtl8139.c for me network = card.=20
Q/ What is the correct compile command for compiling = this c=20 code
once compiled how do I install it
 
or is there a binary file I can use i.e. my P.C. = spec if a=20 clone IBM Pentium I 330
 
Many Thanks in advance
 
you help will be much appreciated
 
 
Anthony Ellison
------=_NextPart_000_0005_01BF2D1D.73C735C0-- | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From pcg@gospelcom.net Fri Nov 12 10:11:49 1999 Date: Fri Nov 12 10:11:49 1999 From: Peter Green pcg@gospelcom.net Subject: two questions On Fri, Nov 12, 1999 at 11:28:59PM +0900, sharkey@ale.physics.sunysb.edu wrote: > > I understand. However, I've tried three different (identical chipset) cards. > > FWIW, the Realtek 8139 is the most problematical chip I have ever used. I > also have three of these cards, and swapping cards never solves a problem. > I've never observed the type of problem you're suggesting, but I'm almost > ready to trash all of mine, too. My cards only have problems once or twice > a month, but, that's still too often for me. These are supposed to go into a remote machine (over 500 miles away); that's enough reason for me to dump these buggers. However, I'll continue pursuing a fix for the problem for posterity's sake. > > It is completely symmetric: > > > > A->B ==> A.TX++, B.RX++ > > B->A ==> B.TX++, A.RX++ > > Hmm. Not likely cabling then. Have you tried using "tcpdump" to view > traffic on the line? These machines must have some sort of two way > communication before a ping can actually be sent. At a minimum you would > need the sender to first issue an arp request and receive an arp reply before > a ping could be sent. You should be able to see all of that with tcpdump. Machine 'A' has the Realtek. Pinging B->A yields the following with tcpdump on A: 09:47:55.568312 P [|llc] 0:0:0:0:0:0:0:0:0:0:0:1 0004 0: One of those per ping. Pinging A->B yields the following with tcpdump on A: 09:48:00.789675 M 6e:3a:20:52:4f:4f 1:0:0:0:0:0 5420 14: although I think that was coincidental. Subsequent pings show nothing. > Does the hardware address of B get into A's arp cache when you issue a ping? Yeah. `arp -an` shows: ? () at on eth0 Likewise, the arp stuff is in B's arp cache, also showing . > I don't really have a clue what your problem is, I'm just poking for more > info that might possibly shed some light on the issue. Donald might just > know everything. He frequently seems to. Thanks for asking the questions, just the same. (P.S. I agree with you about Donald. :) /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Fri Nov 12 10:26:14 1999 Date: Fri Nov 12 10:26:14 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: rtl8139 Driver > I am new to Linux, Welcome. > Q/ What is the correct compile command for compiling this c code > once compiled how do I install it Instructions are available here: http://cesdis.gsfc.nasa.gov/linux/misc/modules.html if you wish to do that. > or is there a binary file I can use i.e. my P.C. spec if a clone IBM = > Pentium I 330 Chances are that a binary module is already included with your Suse distribution. I don't use Suse, but I think most standard distributions will install this module as a default. If its' already installed, all you should need to do is type: modprobe rtl8139 and the driver will be loaded. Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Fri Nov 12 10:40:42 1999 Date: Fri Nov 12 10:40:42 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: two questions > These are supposed to go into a remote machine (over 500 miles away); that's > enough reason for me to dump these buggers. However, I'll continue pursuing > a fix for the problem for posterity's sake. Lucky you. My machines are split between the New York area and the Tokyo area. When something goes wrong, "easy access" is not a likely phrase to pop into mind. Luckily most of the people I work with are fairly competent. > Machine 'A' has the Realtek. Pinging B->A yields the following with tcpdump > on A: > > 09:47:55.568312 P [|llc] > 0:0:0:0:0:0:0:0:0:0:0:1 0004 0: > > One of those per ping. Pinging A->B yields the following with tcpdump on A: > > 09:48:00.789675 M 6e:3a:20:52:4f:4f 1:0:0:0:0:0 5420 14: > > although I think that was coincidental. Subsequent pings show nothing. That's really weird. I may be interpreting that incorrectly, but doesn't that mean that the card is advertising itself as having hardware address 1? What does the hardware address for the realtek appear to be when you type "ifconfig"? > Yeah. `arp -an` shows: > > ? () at on eth0 > > Likewise, the arp stuff is in B's arp cache, also showing . So the arp is failing. If the arp is failing, ping is meaningless. You can bypass arp by setting the entry in the arp cache manually, but I'm not sure what that would tell you if you tried to do that... Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From gary@lowder.com Fri Nov 12 10:50:50 1999 Date: Fri Nov 12 10:50:50 1999 From: Gary Lowder gary@lowder.com Subject: rtl8139 Driver > Anthony Ellison wrote: > I am new to Linux, in fact new to Unix I get to the point, just > purchased a PC installed suse linux 6.2 > download network driver rtl8139.c for me network card. > Q/ What is the correct compile command for compiling this c code > once compiled how do I install it > Hi Anthony, You need to make sure you've got a current kernel source tree, you can go to linux.kernel.org and get it from there. Untar that into /usr/src (after first renaming the current /usr/src/linux to something like /usr/src/linux-old). If you've already got a current source tree then great. For kernel compilation instructions, check /usr/src/linux/README, these are the most up to date instructions for your kernel. You may also check the HOWTO at http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html . Now for the module itsself. Donald Becker has already written some great blow-by-blow instructions for this, it's at http://cesdis.gsfc.nasa.gov/linux/misc/modules.html , of course, substitute the module name rtl8139.c for the driver listed in the text. Hope this helps, compiling kernels will become second nature for you soon, don't worry. Gary Lowder. | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From pcg@gospelcom.net Fri Nov 12 11:01:42 1999 Date: Fri Nov 12 11:01:42 1999 From: Peter Green pcg@gospelcom.net Subject: two questions On Sat, Nov 13, 1999 at 12:40:34AM +0900, sharkey@ale.physics.sunysb.edu wrote: > > Machine 'A' has the Realtek. Pinging B->A yields the following with tcpdump > > on A: > > > > 09:47:55.568312 P [|llc] > > 0:0:0:0:0:0:0:0:0:0:0:1 0004 0: > > > > One of those per ping. Pinging A->B yields the following with tcpdump on A: > > > > 09:48:00.789675 M 6e:3a:20:52:4f:4f 1:0:0:0:0:0 5420 14: > > > > although I think that was coincidental. Subsequent pings show nothing. > > That's really weird. I may be interpreting that incorrectly, but doesn't > that mean that the card is advertising itself as having hardware address > 1? Dunno; this was all of my second excursion with tcpdump. > What does the hardware address for the realtek appear to be when you > type "ifconfig"? 00:00:E8:68:10:07 -- the really weird this is that the address above (6e:3a:20:52:4f:4f) is nowhere to be found on the network. > So the arp is failing. If the arp is failing, ping is meaningless. > > You can bypass arp by setting the entry in the arp cache manually, but I'm > not sure what that would tell you if you tried to do that... I tried this with `arp -s rh6devel.gf.gospelcom.net 00:00:e8:68:10:07` (which was accepted) with no results. :-( /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From becker@cesdis.gsfc.nasa.gov Sat Nov 13 11:53:28 1999 Date: Sat Nov 13 11:53:28 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: two questions On Fri, 12 Nov 1999 sharkey@superk.physics.sunysb.edu wrote: > > A->B ==> A.TX++, B.RX++ > > B->A ==> B.TX++, A.RX++ This is almost certainly a routing problem. When you can transfer packets without errors (checking /proc/net/dev for the counts), but communication does not occur, it's likely someone with the wrong IP addresses, netmask or route. > I don't really have a clue what your problem is, I'm just poking for more > info that might possibly shed some light on the issue. Donald might just > know everything. He frequently seems to. Well, that might change. My new driver versions are not going into the kernel. Instead updates from here and there are being added to the old drivers. As with the Tulip driver, it's too difficult to keep track of the random difference between "v0.89H" in 2.2.5 vs. "v0.89H" in 2.2.10. The list archive question has already been answered. If new rtl8139 support pages are added to www.scyld.com, we will add a search facility. Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From jgarzik@mandrakesoft.com Sat Nov 13 17:32:52 1999 Date: Sat Nov 13 17:32:52 1999 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: Determining RTL-8193 board version? My KTI ethernet board is based on an RTL-8139 chip. Is there any way to tell whether or not this chip is an RTL-1839A or RTL-8139B? Does the driver, or diagnostics program, detect this in any way? Thanks, Jeff -- Jeff Garzik | Just once, I wish we would encounter Building 1024 | an alien menace that wasn't immune to MandrakeSoft, Inc. | bullets. -- The Brigadier, "Dr. Who" | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From gunes_aybay@yahoo.com Sun Nov 14 00:51:09 1999 Date: Sun Nov 14 00:51:09 1999 From: Gunes Aybay gunes_aybay@yahoo.com Subject: Problem with HP1207D-TX 10/100 card I am trying to install Linux on an HP Pavilion 8575C PC, which comes with an HP 1207D-TX 10/100 PCI ethernet card. HP support could not give me pointer to a linux driver for this card, but after some research, it looked like this card was based on the RealTek 8139 chip. I loaded the rtl8139.o module, and the linux boot seemed to recognize the chip. I got the following messge during boot: eth0: SMC1211TX EZCard 10/100 (RealTek RTL8139) at 0x1400, IRQ 0, 00:10:b5:02:fa:88 However, the card does not seem to operate at all. For example, if I do a ping, I don't see any activity (checking the LEDs on the card and on my hub) The same machine/card/network seems to work just fine under Windows 98, so I think my HW setup is OK. I/O base of 0x1400 seems to agree with the information I get on this card when I boot Windows 98. However, IRQ 0 is somewhat suspicious. Windows 98 reports that this card uses IRQ 2/9. Has anybody seen similar problems with the rtl8139 based cards? Has anyone been able to get linux to work with the HP 1207D-TX 10/100 card? Are there any suggestions on what I can do to debug this problem? I don't have much experience with linux but worked with C and UNIX drivers before. Gunes __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From becker@cesdis.gsfc.nasa.gov Sun Nov 14 02:14:52 1999 Date: Sun Nov 14 02:14:52 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: Problem with HP1207D-TX 10/100 card On Sat, 13 Nov 1999, Gunes Aybay wrote: > eth0: SMC1211TX EZCard 10/100 (RealTek RTL8139) at > 0x1400, IRQ 0, 00:10:b5:02:fa:88 .. > I get on this card when I boot Windows 98. However, > IRQ 0 is somewhat suspicious. Windows 98 reports > that this card uses IRQ 2/9. Read http://cesdis.gsfc.nasa.gov/linux/misc/irq-conflict.html You must change your BIOS setup to turn off the misnamed "PnP OS" field. Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From pcg@gospelcom.net Mon Nov 15 16:15:04 1999 Date: Mon Nov 15 16:15:04 1999 From: Peter Green pcg@gospelcom.net Subject: two questions On Sat, Nov 13, 1999 at 12:01:53PM -0500, Donald Becker wrote: Donald, Thanks for writing back, > This is almost certainly a routing problem. When you can transfer > packets without errors (checking /proc/net/dev for the counts), but > communication does not occur, it's likely someone with the wrong IP > addresses, netmask or route. To check, I made sure /proc/net/dev was incrementing during the ping. Where 'A' is the machine with the Realtek cards in it and 'B' is another machine connected via crossover cable: ping A->B: A's transmit bytes and packets incremented ping B->A: A's receive packets (but NOT bytes) incremented A's configuration: [ from dmesg ] eth0: RealTek RTL8139 Fast Ethernet at 0xe400, IRQ 12, 00:00:e8:68:10:07. [ from ifconfig ] eth0 Link encap:Ethernet HWaddr 00:00:E8:68:10:07 inet addr:10.0.0.107 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:158 errors:0 dropped:0 overruns:0 frame:0 TX packets:45 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:12 Base address:0xe40 [ from route ] Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.107 * 255.255.255.255 UH 0 0 0 eth0 10.0.0.0 * 255.0.0.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo Now, that all looks right to me, but I may be wrong. FWIW, I also tried adding a default route of 10.0.0.107 at one point, to no avail... /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From becker@cesdis.gsfc.nasa.gov Mon Nov 15 21:49:04 1999 Date: Mon Nov 15 21:49:04 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: two questions On Mon, 15 Nov 1999, Peter Green wrote: > > This is almost certainly a routing problem. When you can transfer > > packets without errors (checking /proc/net/dev for the counts), but > > communication does not occur, it's likely someone with the wrong IP > > addresses, netmask or route. > > To check, I made sure /proc/net/dev was incrementing during the ping. Where > 'A' is the machine with the Realtek cards in it and 'B' is another machine > connected via crossover cable: > > ping A->B: A's transmit bytes and packets incremented > ping B->A: A's receive packets (but NOT bytes) incremented > A's configuration: What is the configuration of 'B'? > RX packets:158 errors:0 dropped:0 overruns:0 frame:0 > TX packets:45 errors:0 dropped:0 overruns:0 carrier:0 This *really* looks like a routing problem. > Destination Gateway Genmask Flags Metric Ref Use Iface > 10.0.0.107 * 255.255.255.255 UH 0 0 0 eth0 > 10.0.0.0 * 255.0.0.0 U 0 0 0 eth0 > 127.0.0.0 * 255.0.0.0 U 0 0 0 lo Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From J.Blumenschein@gmx.de Wed Nov 17 09:31:40 1999 Date: Wed Nov 17 09:31:40 1999 From: =?ISO-8859-1?Q?J=FCrgen?= Blumenschein J.Blumenschein@gmx.de Subject: subsribe Subsribe -request | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From villano@irsip.na.cnr.it Fri Nov 19 09:50:45 1999 Date: Fri Nov 19 09:50:45 1999 From: Umberto Villano villano@irsip.na.cnr.it Subject: AT2500 nic upgrade I have an Allied Telesyn AT2500Tx nic. It worked under Linux using the rtl8139 driver. After all sort of problems under WIN98, I patched the EEPROM card contents (it should fix the ACPI compatibility), using the program at the URL ftp://ftp.alliedtelesyn.com/pub/2500nic/ACPI-KIT.exe Now the card works under WIN98, but not under Linux. I have updated the driver of my RedHat 6.0 distribution to version 1.08a, and the adapter still does not work. This is the output of the diagnostic program: [root@wheel /root]# ./rtl8139-diag -a rtl8139-diag.c:v1.01 4/30/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a RealTek RTL8139 adapter at 0xc400. RealTek chip registers at 0xc400 0x000: 1bd2a000 0000c1d9 80004100 00000000 00002000 00002000 00002000 00002000 0x020: 00fdb800 00fda000 00fda800 00fdb000 00fd2000 01000000 0000fff0 20000000 0x040: 70000000 00000000 8439e509 00000000 000f10c6 00000000 0000e108 00100000 0x060: 1000000f 05e1782d 00000000 00000000 00000005 000f77c0 78fa8388 ad38de43. No interrupt sources are pending. (null) indication. The chip configuration is 0x10 0x0f, MII half-duplex mode. [root@wheel /root]# ./rtl8139-diag -e rtl8139-diag.c:v1.01 4/30/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a RealTek RTL8139 adapter at 0xc400. Parsing the EEPROM of a RealTek chip: PCI IDs -- Vendor 0x10ec, Device 0x8139, Subsystem 0x1259. PCI timer settings -- minimum grant 32, maximum latency 64. General purpose pins -- direction 0xe1 value 0x10. Station Address 00:A0:D2:1B:D9:C1. Configuration register 0/1 -- 0x0d / 0xc2. EEPROM active region checksum is 093e. [root@wheel /root]# ./rtl8139-diag -m rtl8139-diag.c:v1.01 4/30/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a RealTek RTL8139 adapter at 0xc400. The RTL8139 does not use a MII transceiver. It does have internal MII-compatible registers: Basic mode control register 0x782d. Basic mode status register 0x1000. Autonegotiation Advertisement 0x05e1. Link Partner Ability register 0x0000. Autonegotiation expansion 0x0000. Disconnects 0x0000. False carrier sense counter 0x0000. NWay test register 0x0005. Receive frame error count 0x0000. [root@wheel /root]# Any suggestions? Umberto ============================================ prof. Umberto Villano Universita' del Sannio Facolta' di Ingegneria Palazzo Bosco Lucarelli, C.so Garibaldi 107 82100 Benevento Italy tel. +39-0824-305804 fax +39-0824-21866 e-mail: villano@unina.it ============================================ | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From bxp163@psu.edu Mon Nov 22 20:37:30 1999 Date: Mon Nov 22 20:37:30 1999 From: Brian Pacansky bxp163@psu.edu Subject: No subject Is there any way to force the 8139 into 10mbit mode in linux? | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From mdione@hal.famaf.unc.edu.ar Tue Nov 23 15:01:18 1999 Date: Tue Nov 23 15:01:18 1999 From: Marcos Dione mdione@hal.famaf.unc.edu.ar Subject: unknown errors hi, I'm administrating 90 compaqs which came with the rtl8139. i'm using mdk-6.1 (i.e., kernel 2.2.13). the problem is: copying large files (with large=1Gb) from one machine to another I ramdonly get error messages like etho: Transmit timeout, status 0d000 media 00 : Tx queue start entry x+4 dirty entry x where x is some number. while the error isn't present, the copy is smooth, but when it shows, the copy stops a while, and restart after a ramdon time ranging from 1 min to never! any hint? | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From chirapol@nectec.or.th Wed Nov 24 00:10:01 1999 Date: Wed Nov 24 00:10:01 1999 From: Chirapol Mathawaphan chirapol@nectec.or.th Subject: AT2500TX I'm using AT2500TX card (RealTek 8139) on redhat 6.1 but face a lot of packet loss and checksum error problems. I tried changing the rtl8139 module got from http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html web site, but the packet loss and check sum error improved a bit. Are these problems caused by the rtl8139 driver? Has anybody experienced the same problem? I've done card diagnosting (DOS), the result show that the card is working properly. The cable works fine with 3Com card. Chirapol. | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From mdione@hal.famaf.unc.edu.ar Wed Nov 24 16:03:28 1999 Date: Wed Nov 24 16:03:28 1999 From: Marcos Dione mdione@hal.famaf.unc.edu.ar Subject: question as I've seen, this chipset seems to be like a pile of shit. I mean, here I see a lot of problems and the common factor is that chiset, so: is this the worst chipset ever built? I mean, if you can choose from all the somehow-low-end chipset, would you choose this one? I'm not joking, I'm plannig migrate from this NIC to another one... 90 troubles poking and fingering my face every day ain't a nice job! | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From tbrobst@cjnetworks.com Sun Nov 28 07:28:20 1999 Date: Sun Nov 28 07:28:20 1999 From: Tim Brobst tbrobst@cjnetworks.com Subject: NIC driver compiling errors/problems Hi everyone, I have the Kingston KNE120TX EtheRx nic for my ADSL line and my RH6.0 doesn't have a driver for this card. Being somewhat of a newbe in linux I would like to get some experience doing some downloading and compiling. I have been in contact with Kingston and they are "working" on my problem. They have referred me to this site (http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.c) for the driver for my nic card. Here is my problems, I have used both compile commands, (the one from the bottom of this driver page, and one that Kingston forwarded to me via email) the commands are the same except the one from Kingston has an added line. From the page: "gcc -DMODULE -D_KERNEL_ -Wall -Wstrict-prototypes -O6 -c rtl8139.c And here is the one that Kingston sent: gcc -DMODULE -D_KERNEL_ -Wall -Wstrict-prototypes -O6 -c rtl8139.c '[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS' When i use the first command I get the following information lines and errors: rtl8139.c:61:warning: #Warning You must compile this file with the correct options! rtl8139.c:62:warning: #Warning See the last lines of the source file. rtl8139.c:63:warning: #error You must compile this driver with "-O". I get the same information lines and errors when I run the command that Kingston sent me, except this "gcc" line comes in before all the rest: gcc: [ -f /usr/src/linux/modversions.h ] && echo -DMODVERSIONS: no such file or directory. I have followed all paths and have everything that's is listed in both commands, so I don't understand the "no such file or directory" that the second command returns. I have noticed that if I try to go into the /usr/src/linux directory it sends me into /usr/src/linux2.2.5 directory, why I have no idea, acts almost like a default path. I have downloaded the file into /usr/src/linux as I am told, but it shows up in the /usr/src/linux2.2.5 directory showing the same result as trying to get into the /linux directory of the same path. Any help is appreciated Tim Brobst tbrobst@cjnetworks.com | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From becker@cesdis.gsfc.nasa.gov Mon Nov 29 15:12:44 1999 Date: Mon Nov 29 15:12:44 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: NIC driver compiling errors/problems On Sun, 28 Nov 1999, Tim Brobst wrote: > my nic card. Here is my problems, I have used both compile commands, > (the one from the bottom of this driver page, and one that Kingston > forwarded to me via email) the commands are the same except the one from > > Kingston has an added line. From the page: > "gcc -DMODULE -D_KERNEL_ -Wall -Wstrict-prototypes -O6 -c rtl8139.c > rtl8139.c:61:warning: #Warning You must compile this file with the > correct options! > rtl8139.c:62:warning: #Warning See the last lines of the source file. That should be "-D__KERNEL__" in the compile line. > I get the same information lines and errors when I run the command that > Kingston sent me, except this "gcc" line comes in before all the rest: > gcc: [ -f /usr/src/linux/modversions.h ] && echo -DMODVERSIONS: no such > file or directory. > > I have followed all paths and have everything that's is listed in both > commands, so I don't understand the "no such file or directory" that the > > second command returns. I have noticed that if I try to go into the You missed the backquotes, "`". Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From td@salesint.com Tue Nov 30 08:47:22 1999 Date: Tue Nov 30 08:47:22 1999 From: Technical Service - Sales International Holland B.V. td@salesint.com Subject: How to compile driver into kernel This is a multi-part message in MIME format. ------=_NextPart_000_0016_01BF3B41.DBECB760 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey there, I was wondering if it's possible to compile the driver into the kernel = like used to be possible. I used to run kernel 2.0.35 which has the = support for the Realtek 8139 build into it (driver shows up under the = menuconfig) however version 2.2.5 and 2.2.13 for some reason don't have = the driver. Now I was wondering how to compile the driver into the = kernel and why the driver isn't shipped with the kernel anymore. Thanks for any help. Kind regards, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D * Ferry van Steen, Technical Service * Sales International Holland B.V. * E-Mail: td@salesint.com * Homepage: http://www.salesint.com * ICQ (Private): 191458 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D ------=_NextPart_000_0016_01BF3B41.DBECB760 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hey there,
 
I was wondering if it's possible to compile the = driver into=20 the kernel like used to be possible. I used to run kernel 2.0.35 which = has the=20 support for the Realtek 8139 build into it (driver shows up under the=20 menuconfig) however version 2.2.5 and 2.2.13 for some reason don't have = the=20 driver. Now I was wondering how to compile the driver into the kernel = and why=20 the driver isn't shipped with the kernel anymore.
 
Thanks for any help.
 
Kind regards,
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
* Ferry van Steen,=20 Technical Service
* Sales International Holland B.V.
* E-Mail: td@salesint.com
* Homepage: http://www.salesint.com
* ICQ = (Private):=20 191458
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------=_NextPart_000_0016_01BF3B41.DBECB760-- | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From sharkey@superk.physics.sunysb.edu Tue Nov 30 09:53:09 1999 Date: Tue Nov 30 09:53:09 1999 From: sharkey@superk.physics.sunysb.edu sharkey@superk.physics.sunysb.edu Subject: How to compile driver into kernel > I was wondering if it's possible to compile the driver into the kernel = > like used to be possible. I used to run kernel 2.0.35 which has the = > support for the Realtek 8139 build into it (driver shows up under the = > menuconfig) however version 2.2.5 and 2.2.13 for some reason don't have = > the driver. Now I was wondering how to compile the driver into the = > kernel and why the driver isn't shipped with the kernel anymore. What are you talking about? It's still there. I'm running 2.2.13 with 8139 support compiled in directly. It's still in the menu. Eric | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible. From mdione@hal.famaf.unc.edu.ar Tue Nov 30 12:05:16 1999 Date: Tue Nov 30 12:05:16 1999 From: Marcos Dione mdione@hal.famaf.unc.edu.ar Subject: unknown errors (fwd) again... ---------- Forwarded message ---------- Date: Tue Nov 30 12:05:16 1999 From: Marcos Dione To: linux-realtek@beowulf.gsfc.nasa.gov Subject: unknown errors hi, I'm administrating 90 compaqs which came with the rtl8139. i'm using mdk-6.1 (i.e., kernel 2.2.13). the problem is: copying large files (with large=1Gb) from one machine to another I ramdonly get error messages like etho: Transmit timeout, status 0d000 media 00 : Tx queue start entry x+4 dirty entry x where x is some number. while the error isn't present, the copy is smooth, but when it shows, the copy stops a while, and restart after a ramdon time ranging from 1 min to never! any hint? | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the | body of the mail, include only the text: | unsubscribe this-list-name youraddress@wherever.org | You will be unsubscribed as speedily as possible.