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