From dbaldwin@optonline.net Sun, 1 Oct 2000 09:55:16 -0400 Date: Sun, 1 Oct 2000 09:55:16 -0400 From: Doug dbaldwin@optonline.net Subject: [realtek] Is the 4 bytes too long bug fixed???? This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C02B8D.B36815E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I too see the 4 byte bug, this time with dhclient. The message reads: = "ip length 328 disagrees with bytes received 332." This is causing = other problems too. One note in the archive included a possible = solution, which is pasted below. Has this batch made its way into the = source? Please reply if you've used this patch either successfully or = unsuccessfully. By the way, my platform is 2.2.16. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pasted from archive = =3D=3D=3D=3D=3D=3D=3D=3D=3D I have a solution to the problem. By changing the following lines in the rtl8129_rx funtion (around line 1260): #if 1 /* USE_IP_COPYSUM */ eth_copy_and_sum(skb, &rx_ring[ring_offset + 4], rx_size, 0); skb_put(skb, rx_size); #else to #if 1 /* USE_IP_COPYSUM */ eth_copy_and_sum(skb, &rx_ring[ring_offset + 4], rx_size - 4, 0); skb_put(skb, rx_size - 4); #else This removes the 32 bit status word from the packet data. =20 /Markus ------=_NextPart_000_0007_01C02B8D.B36815E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I too see the 4 byte bug, this time = with=20 dhclient.  The message reads: "ip length 328 disagrees with bytes = received=20 332."  This is causing other problems too.  One note in the = archive=20 included a possible solution, which is pasted below.  Has this = batch made=20 its way into the source? Please reply if you've used this patch = either=20 successfully or unsuccessfully.
 
By the way, my platform is = 2.2.16.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pasted from archive =
=3D=3D=3D=3D=3D=3D=3D=3D=3D
I have a solution to the problem. =
By changing the following lines in the
rtl8129_rx funtion (around line 1260):

#if 1  /* USE_IP_COPYSUM */
            eth_copy_and_sum(skb, &rx_ring[ring_offset + 4],
                         rx_size, 0);
            skb_put(skb, rx_size);
#else

to

#if 1  /* USE_IP_COPYSUM */
            eth_copy_and_sum(skb, &rx_ring[ring_offset + 4],
                         rx_size - 4, 0);
            skb_put(skb, rx_size - 4);
#else

This removes the 32 bit status word from the packet data. =20

/Markus


------=_NextPart_000_0007_01C02B8D.B36815E0-- From jgarzik@mandrakesoft.mandrakesoft.com Sun, 1 Oct 2000 08:59:50 -0500 (CDT) Date: Sun, 1 Oct 2000 08:59:50 -0500 (CDT) From: Jeff Garzik jgarzik@mandrakesoft.mandrakesoft.com Subject: [realtek] Is the 4 bytes too long bug fixed???? On Sun, 1 Oct 2000, Doug wrote: > I too see the 4 byte bug, this time with dhclient. The message reads: "ip length 328 disagrees with bytes received 332." This is causing other problems too. One note in the archive included a possible solution, which is pasted below. Has this batch made its way into the source? Please reply if you've used this patch either successfully or unsuccessfully. Your e-mail client is broken, please turn on word wrap. Yes, the "4 byte bug" is fixed in 2.2.18-pre kernels, and also in 2.4.x kernels. Don Becker's external rtl8139.c also fixes this bug, but it has other bugs in all version on his site, so I would not recommend using it at this time. Jeff From wpaulson@lucent.com Tue, 03 Oct 2000 17:17:51 -0500 Date: Tue, 03 Oct 2000 17:17:51 -0500 From: William Paulson wpaulson@lucent.com Subject: [realtek] Transmit timeout bug - still there? I'm running kernel 2.3.99pre9 with the 0.9.10 version of 8139too.c. Under moderate transmit load, the Realtek 8139 ethernet adapter appears to stop receiving from the network after a short time. The syslog shows a NETDEV: WATCHDOG eth0: transmit timed out message at about the time of the failure. I've perused the mailing list - although this problem's been mentioned many times, it wasn't clear whether the problem still existed with the most recent software. It looks like it's still there. Bill Paulson wpaulson@lucent.com From jvalkiunas@ChicagoJava.com Mon, 9 Oct 2000 15:20:01 -0500 Date: Mon, 9 Oct 2000 15:20:01 -0500 From: Jonas Valkiunas jvalkiunas@ChicagoJava.com Subject: [realtek] Module loading at startup All, I have 2 nics in a firewall, a tulip and a realtek, running in a RH6.2/2.2.17/x86 environment. I compiled all 3 drivers w/ no problems (pci-scan, tulip, rtl8139) and everything works well after I manually insmod in that order. The problem: upon boot eth0 (tulip) is loaded, but the realtek driver is not. Obviously pci-scan is loaded too, but I have to manually insmod rtl8139 and restart networking in order to get everything back up in harmony. The question: why isn't the realtek driver loading upon startup? Is it practical to manually add a 'insmod /lib/'uname -r'/net/rlt8139' in a startup script? Keep in mind everything works fine if I manually load the driver... Following are some systems messages that might be helpful. Thanks! -Jonas Here's a cat of /proc/pci: (after manual loading) # cat /proc/pci Ethernet controller: LiteOn LNE100TX (rev 33). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=66. I/O at 0xf400 [0xf401]. Non-prefetchable 32 bit memory at 0xffbee800 [0xffbee800]. Bus 0, device 19, function 0: Ethernet controller: Realtek 8139 (rev 16). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=66. Min Gnt=32.Max Lat=64. I/O at 0xf800 [0xf801]. Non-prefetchable 32 bit memory at 0xffbeec00 [0xffbeec00]. # ifconfig eth0 Link encap:Ethernet HWaddr 00:A0:CC:3D:1D:D3 inet addr:*.*.*.* Bcast:*.*.*.* Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:333923 errors:0 dropped:0 overruns:0 frame:0 TX packets:247037 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0x800 eth1 Link encap:Ethernet HWaddr 00:50:BA:85:77:1F inet addr:*.*.*.* Bcast:*.*.*.* Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:430235 errors:0 dropped:0 overruns:0 frame:0 TX packets:150249 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0xf800 From becker@scyld.com Mon, 9 Oct 2000 19:22:05 -0400 (EDT) Date: Mon, 9 Oct 2000 19:22:05 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] Module loading at startup On Mon, 9 Oct 2000, Jonas Valkiunas wrote: > I have 2 nics in a firewall, a tulip and a realtek, running in a > RH6.2/2.2.17/x86 environment. I compiled all 3 drivers w/ no problems > (pci-scan, tulip, rtl8139) and everything works well after I manually insmod > in that order. > > The problem: upon boot eth0 (tulip) is loaded, but the realtek driver is > not. Obviously pci-scan is loaded too, but I have to manually insmod > rtl8139 and restart networking in order to get everything back up in > harmony. Make certain that the following line appears in /etc/conf.modules: ________________ alias eth1 rtl8139 ________________ That evil "kudzu" program is supposed to do this in RH6.2. Evil, evil, evil.. 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 jvalkiunas@ChicagoJava.com Tue, 10 Oct 2000 08:41:23 -0500 Date: Tue, 10 Oct 2000 08:41:23 -0500 From: Jonas Valkiunas jvalkiunas@ChicagoJava.com Subject: [realtek] Module loading at startup Donald, you're the man...this did the trick: cat /etc/conf.modules: alias eth0 tulip alias eth1 realtek changed to: alias eth0 tulip alias eth1 rtl8139 Now, I suppose the makers of Kudzu/RH should be made aware...? Thanks! -Jonas -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Monday, October 09, 2000 6:22 PM To: Jonas Valkiunas Cc: realtek@scyld.com Subject: Re: [realtek] Module loading at startup On Mon, 9 Oct 2000, Jonas Valkiunas wrote: > I have 2 nics in a firewall, a tulip and a realtek, running in a > RH6.2/2.2.17/x86 environment. I compiled all 3 drivers w/ no problems > (pci-scan, tulip, rtl8139) and everything works well after I manually insmod > in that order. > > The problem: upon boot eth0 (tulip) is loaded, but the realtek driver is > not. Obviously pci-scan is loaded too, but I have to manually insmod > rtl8139 and restart networking in order to get everything back up in > harmony. Make certain that the following line appears in /etc/conf.modules: ________________ alias eth1 rtl8139 ________________ That evil "kudzu" program is supposed to do this in RH6.2. Evil, evil, evil.. 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 hrohit@hotmail.com Sat, 14 Oct 2000 10:02:19 GMT Date: Sat, 14 Oct 2000 10:02:19 GMT From: Rohit Agarwal hrohit@hotmail.com Subject: [realtek] 8139c and linux7 Hi, I am using rtl8139c from Edimax on a Redhatlinux 7 machine using the driver which came in /lib/modules/2.2.16-22/net/ I also did the linuxconf and dhcpcd settings, but while booting: 1. error msg comes the eth0 initialization failes, and module doesn't get loaded. 2. even after I manually load the module, it doesn't work and says "host unreachable". Pls help me on this. I am trying to connect to @Home modem service vis dhcp. Thanks Rohit _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From sharkey@ale.physics.sunysb.edu Sat, 14 Oct 2000 08:26:27 -0400 Date: Sat, 14 Oct 2000 08:26:27 -0400 From: sharkey@ale.physics.sunysb.edu sharkey@ale.physics.sunysb.edu Subject: [realtek] 8139c and linux7 > Hi, > I am using rtl8139c from Edimax on a Redhatlinux 7 machine using the driver > which came in /lib/modules/2.2.16-22/net/ > I also did the linuxconf and dhcpcd settings, but while booting: > > 1. error msg comes the eth0 initialization failes, and module doesn't get > loaded. Can you be more specific? What is the exact error you see? > 2. even after I manually load the module, it doesn't work and says "host > unreachable". If you load the module without configuring the interface then you won't have a route out so all hosts will be unreachable. That's normal. If you're using DHCP, you need to restart the dhcp client to get a new dhcp lease. The client should configure the interface for you. Eric From seanm@netwinder.org Tue, 17 Oct 2000 15:43:03 -0400 (EDT) Date: Tue, 17 Oct 2000 15:43:03 -0400 (EDT) From: Sean MacLennan seanm@netwinder.org Subject: [realtek] 8139c prom Hi, I am trying to find the proper settings for the realtek 8139C eprom. Specifically, I am looking for the values for PHY1_PARM_U and PHY2_PARM_U. If you have an 8139C (not a B or A), I have a program to read the prom. Thanks, Sean -- From becker@scyld.com Tue, 17 Oct 2000 16:35:40 -0400 (EDT) Date: Tue, 17 Oct 2000 16:35:40 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] 8139c prom On Tue, 17 Oct 2000, Sean MacLennan wrote: > From: Sean MacLennan Interesting domain name.. > I am trying to find the proper settings for the realtek 8139C > eprom. Specifically, I am looking for the values for PHY1_PARM_U and > PHY2_PARM_U. If you have an 8139C (not a B or A), I have a program to read > the prom. You mean the serial EEPROM, correct? I believe that those values set the twister parameters, and may differ between chips. I suspect (don't know for certain, but I do have an EE degree from MIT and have spent too much time in a clean room:-O ) that the values are based on the analog characterists of the specific die. Using the value from an apparently similar chip might not work with long, kinked or low-grade cables. BTW, you can use 'rtl8139-diag -ee' to show the EEPROM contents. 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 Jia.Hua@tfn.com Wed, 18 Oct 2000 18:15:29 -0400 Date: Wed, 18 Oct 2000 18:15:29 -0400 From: Hua, Jia Jia.Hua@tfn.com Subject: [realtek] Weird problem! RTL 8139 can transmit but not receive Hi, All, I have a weird problem with my RTL8139 cards(the cards are from Hawking Tech.). I have two linux boxes connected by a mini hub. One is PII 400, asus p2b AGP motherboard, with dual(triple) boot(Linux ReHat6.0, NT, 98). Another is P75 Packard Bell with Linux ReHat6.0 only. When trying the peer to peer network, I boot Linux on both boxes. I downloaded the latest driver from website, and complied the module. Everything looks fine at the beginning, both my linux boxes can detect the card. But I can not ping each other. When I ping the other one, I can see the led blinks on the hub, and the other card's led blinks also. I use the ifconfig eth0 to check the status, and I can see the TX packet with some numbers, but RX number is always 0! I believe I set right for the IP and route, which are 192.168.0.1 with 255.255.255.0 and 192.168.0.2 with 255.255.255.0. I use mii-diag, and it reports 782d for status. I really don't know what else I should check. Could anyone give me some hints? Thanks a lot! Joe H. From hua200@hotmail.com Wed, 18 Oct 2000 18:14:58 -0400 Date: Wed, 18 Oct 2000 18:14:58 -0400 From: Jia H. hua200@hotmail.com Subject: [realtek] Weird problem! RTL 8139 can transmit but not receive Hi, All, I have a weird problem with my RTL8139 cards(the cards are from Hawking Tech.). I have two linux boxes connected by a mini hub. One is PII 400, asus p2b AGP motherboard, with dual(triple) boot(Linux ReHat6.0, NT, 98). Another is P75 Packard Bell with Linux ReHat6.0 only. When trying the peer to peer network, I boot Linux on both boxes. I downloaded the latest driver from website, and complied the module. Everything looks fine at the beginning, both my linux boxes can detect the card. But I can not ping each other. When I ping the other one, I can see the led blinks on the hub, and the other card's led blinks also. I use the ifconfig eth0 to check the status, and I can see the TX packet with some numbers, but RX number is always 0! I believe I set right for the IP and route, which are 192.168.0.1 with 255.255.255.0 and 192.168.0.2 with 255.255.255.0. I use mii-diag, and it reports 782d for status. I really don't know what else I should check. Could anyone give me some hints? Thanks a lot! Joe H. From lynn@freespeech.org Fri, 20 Oct 2000 20:49:43 -0600 (MDT) Date: Fri, 20 Oct 2000 20:49:43 -0600 (MDT) From: Lynn Winebarger lynn@freespeech.org Subject: [realtek] NFS problem (using realtek) I've got a little 4 machine network, with one machine an nfs server and another running an active webserver (on a separate interface to the outside world). The other 2 machines aren't currently being used much (but will be). All the NICs hooked up to the 4 machine network are DLink 530TX's with rtl8139 chips. This morning I was copying a few hundred megabytes worth of files over NFS from machine #3, and the webserver machine's load went through the roof (because all the httpd processes were in an uninterruptable sleep, waiting on NFS). I tried pinging the nfs server, and got back responses in pairs, where one would be about 0.3 ms, and the other 1000 ms. I shut down the copying process, waited a couple of minutes, and pinging the nfs server got the same results. I waited a few minutes more, tested again, same results, rebooted the server, worked fine. (machine #3 didn't experience any of these problems, though it also uses the rtl8139 driver). Anyway, I see similar problems are reported for the rtl8139 driver in the archives. I'm using Redhat 6.2, with kernel 2.2.16-3 on the webserver. Looks like the rtl8139 driver is 1.07. Would upgrading to 1.10 fix this problem? Is there a fix in the near future? I'm going to be building a small cluster of webservers using this nfs server, and buying a bunch of NICs, so I'd like to know whether avoiding realtek 8139 based cards is necessary (looking at the tulip list, looks like they're not suffering from the same problem). Thanks, Lynn From 42ff@gmx.net Sat, 21 Oct 2000 20:06:04 +0200 Date: Sat, 21 Oct 2000 20:06:04 +0200 From: Florian Friesdorf 42ff@gmx.net Subject: [realtek] NFS problem (using realtek) --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2000 at 08:49:43PM -0600, Lynn Winebarger wrote: >=20 > I've got a little 4 machine network, with one machine an nfs server and > another running an active webserver (on a separate interface to the > outside world). The other 2 machines aren't currently being used much > (but will be). All the NICs hooked up to the 4 machine network are DLink > 530TX's with rtl8139 chips. =20 > This morning I was copying a few hundred megabytes worth of files over > NFS from machine #3, and the webserver machine's load went through the > roof (because all the httpd processes were in an uninterruptable sleep, > waiting on NFS). I tried pinging the nfs server, and got back responses > in pairs, where one would be about 0.3 ms, and the other 1000 ms. I shut > down the copying process, waited a couple of minutes, and pinging the nfs > server got the same results. I waited a few minutes more, tested again, > same results, rebooted the server, worked fine. (machine #3 didn't > experience any of these problems, though it also uses the rtl8139 driver). > Anyway, I see similar problems are reported for the rtl8139 driver in > the archives. I'm using Redhat 6.2, with kernel 2.2.16-3 on the > webserver. Looks like the rtl8139 driver is 1.07. Would upgrading to > 1.10 fix this problem? Is there a fix in the near future? > I'm going to be building a small cluster of webservers using this nfs > server, and buying a bunch of NICs, so I'd like to know whether avoiding > realtek 8139 based cards is necessary (looking at the tulip list, looks > like they're not suffering from the same problem). I experience the same phenomenon with stock 2.2.15 rtl8139 driver. (ifconfig eth0 down && ifconfig eth0 up) & on the problematic machine will work as a temporary fix. (btw: save to executed over ssh, without loosing connectivity) I think there is "some type of overflow" as using the following cron.d entry worked fine up till now. 00 * * * * root /sbin/ifconfig eth0 down && /sbin/ifconfig eth0 up ok, it's not the elegant way, but works fine 'til I have some more spare time. regards ff --=20 Florian Friesdorf <42ff@gmx.net> OpenPGP key available on public key servers ------> Save the future of Open Source <------ -> Online-Petition against Software Patents <- ------> http://petition.eurolinux.org <------- --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE58dsMf/ev6c/2/tARAmv7AKCcuKX8Zc3DJzXyIX9oUTaUZ1ssHgCfdY1+ fBFL9l5lHV50DqEDlnsg9N4= =Tc19 -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From paul@taniwha.com Sat, 21 Oct 2000 11:45:32 -0700 Date: Sat, 21 Oct 2000 11:45:32 -0700 From: Paul Campbell paul@taniwha.com Subject: [realtek] NFS problem (using realtek) On Saturday 21 October 2000 11:06 am, Florian Friesdorf wrote: > > This morning I was copying a few hundred megabytes worth of files over > > NFS from machine #3, and the webserver machine's load went through the > > roof (because all the httpd processes were in an uninterruptable sleep, > > waiting on NFS). I tried pinging the nfs server, and got back responses > > in pairs, where one would be about 0.3 ms, and the other 1000 ms. > I experience the same phenomenon with stock 2.2.15 rtl8139 driver. > > (ifconfig eth0 down && ifconfig eth0 up) & > > on the problematic machine will work as a temporary fix. > (btw: save to executed over ssh, without loosing connectivity) > Actually I found this bug and submitted a fix which I believe is in included in 1.11 or later (it's a receive collision recovery bug). You can also quickly get an offending machine out of this state with a bunch of 10k byte pings Paul Campbell From jonas@jalling.dk Sun, 22 Oct 2000 07:44:49 -0400 (EDT) Date: Sun, 22 Oct 2000 07:44:49 -0400 (EDT) From: Jonas B. Jalling jonas@jalling.dk Subject: [realtek] Problems with realtek8139 and linux Hi, I'm trying to install linux on my laptop computer. There is no cdrom in the computer, so im doing the installprocess over the network. But i can't get the netcard working with the mandrake pcmcia bootdisk. The netcard is using Cardbus. I don't think, that the bootdisk are supporting the rtl8139.o if it is using Carbus, but how can i update the driver on the disk, to support the Cardbus driver?? /Jonas From Karl.Bellve@umassmed.edu Tue, 24 Oct 2000 14:42:34 -0400 Date: Tue, 24 Oct 2000 14:42:34 -0400 From: Karl Bellve Karl.Bellve@umassmed.edu Subject: [realtek] compiling rtl8139 for 2.4 kernel? I looked over the archives and saw only one answer for this, which was to use the 8139too driver. I would rather stay with Donald Becker's driver. Is there a patch for rtl8139 to use with the latest kernels? I am building a file server to use with our Alpha Beowulf system (32 node 21264 with myrinet). This file server is using 2 promise Ultra100 IDE controller cards controller 4 75GB drives, which is why I need to use the 2.4 kernel. So, is there a patch for rtl1839.c or do I need to use 8139too? TIA -- Cheers, Karl Bellve, Ph.D. ICQ # 13956200 Biomedical Imaging Group TLCA# 7938 University of Massachusetts Email: Karl.Bellve@umassmed.edu Phone: (508) 856-6514 Fax: (508) 856-1840 PGP Public key: finger kdb@molmed.umassmed.edu From 42ff@gmx.net Thu, 26 Oct 2000 02:49:04 +0200 Date: Thu, 26 Oct 2000 02:49:04 +0200 From: Florian Friesdorf 42ff@gmx.net Subject: [realtek] compiling rtl8139 for 2.4 kernel? --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2000 at 02:42:34PM -0400, Karl Bellve wrote: >=20 > I looked over the archives and saw only one answer for this, which was > to use the 8139too driver. I would rather stay with Donald Becker's > driver. Is there a patch for rtl8139 to use with the latest kernels? >=20 > I am building a file server to use with our Alpha Beowulf system (32 > node 21264 with myrinet). This file server is using 2 promise Ultra100 > IDE controller cards controller 4 75GB drives, which is why I need to > use the 2.4 kernel.=20 There are udma kernel patches for 2.2.17 available from hedrick. ftp://ftp.kernel.org/pub/linux/kernel/people/hedrick > So, is there a patch for rtl1839.c or do I need to use 8139too? In my expierence the 8139too seems to more stable than rtl8139 regards florian --=20 Florian Friesdorf <42ff@gmx.net> OpenPGP key available on public key servers ------> Save the future of Open Source <------ -> Online-Petition against Software Patents <- ------> http://petition.eurolinux.org <------- --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE593+Af/ev6c/2/tARAtOlAKCUeaVLz+McR8njIbEfoZxXVrBj5QCgkSFA MXJo6sC3/5uBkysnXWlrffs= =YMxI -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From hchcheng@scg.math.uwaterloo.ca Mon, 30 Oct 2000 16:00:26 -0500 (EST) Date: Mon, 30 Oct 2000 16:00:26 -0500 (EST) From: Howard Cheng hchcheng@scg.math.uwaterloo.ca Subject: [realtek] Oversized Ethernet frame Hi, I have scanned through the mailing list archive and I don't seem to find any definitive resolution on this one. I am getting Oct 30 15:10:41 scg7 kernel: eth0: Oversized Ethernet frame, status cccccccc! Oct 30 15:10:41 scg7 kernel: eth0: Abnormal interrupt, status 00000021. every once in a while (when traffic is high), and I have to manually ifdown and ifup the interface. Some information about my network card: scg7:~#rtl8139-diag -aa rtl8139-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a SMC1211TX EZCard 10/100 (RealTek RTL8139) adapter at 0xb000. 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 0xb000 0x000: 6b29e000 0000a873 80000000 00000000 0008a042 0008a092 0008a042 0008a096 0x020: 07778010 07778610 07778c10 07779210 07770000 0d0a0000 c0ccc0bc 0000c07f 0x040: 78000400 0000940e 589f006b 00000000 006c10c6 00000000 0084c110 00100040 0x060: 1100f00f 05e1782d 00014101 00000000 00000004 000937c8 58fab388 ad38d843. No interrupt sources are pending. The chip configuration is 0x10 0x6c, MII full-duplex mode. EEPROM size test returned 6, 0x204a4 / 0x2. scg7:~#rtl8139-diag -ee rtl8139-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a SMC1211TX EZCard 10/100 (RealTek RTL8139) adapter at 0xb000. EEPROM size test returned 6, 0x204a4 / 0x2. Parsing the EEPROM of a RealTek chip: PCI IDs -- Vendor 0x1113, Device 0x1211, Subsystem 0x1113. PCI timer settings -- minimum grant 32, maximum latency 64. General purpose pins -- direction 0xc1 value 0x10. Station Address 00:E0:29:6B:73:A8. Configuration register 0/1 -- 0x0d / 0xc2. EEPROM active region checksum is 05e6. EEPROM contents: 8129 1113 1211 1113 1211 4020 c110 e000 6b29 a873 0d10 0fc2 8401 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 0x0686. scg7:~#rtl8139-diag -mm rtl8139-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a SMC1211TX EZCard 10/100 (RealTek RTL8139) adapter at 0xb000. EEPROM size test returned 6, 0x204a4 / 0x2. Sorry for including so much. Not sure what you will need. I am running Linux 2.2.16-3 and Red Hat 6.2. Any help would be deeply appreciated. Howard --- Howard Cheng e-mail: hchcheng@scg.math.uwaterloo.ca University of Waterloo URL : http://www.scg.uwaterloo.ca/~hchcheng/ Computer Science Graduate Student (PhD) The ultimate goal of mathematics is to eliminate any need for intelligent thought. - Alfred N. Whitehead