From rajarshi@setindia.com Wed, 1 Aug 2001 17:45:07 +0530 Date: Wed, 1 Aug 2001 17:45:07 +0530 From: The Saintly King rajarshi@setindia.com Subject: [realtek] (no subject) This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C11AB1.B3C5C1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi=20 sir=20 how r u i have some problem to search the dirver of the lan card, that is "Realtek RTL8139 (A/B/C/8130) PCI Fast Ethernet = NIC" driver. please send me the Card driver in my E-mail Account that is mailto:psahu123@yahoo.com ------=_NextPart_000_0005_01C11AB1.B3C5C1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
sir
how r u
 
i have some problem to search the=20 dirver
of the lan card, that is "Realtek = RTL8139=20 (A/B/C/8130) PCI Fast Ethernet NIC" driver.
 
please send me the Card driver in my = E-mail=20 Account
 
that is mailto:psahu123@yahoo.com
 
------=_NextPart_000_0005_01C11AB1.B3C5C1E0-- From Julien.Cubizolles@lkb.ens.fr Wed, 1 Aug 2001 19:33:28 +0200 (CEST) Date: Wed, 1 Aug 2001 19:33:28 +0200 (CEST) From: Julien Cubizolles Julien.Cubizolles@lkb.ens.fr Subject: [realtek] Insmod problem I cannot load the 8139too module for my pcmcia ethernet card. First, my card is not recognized by default by cardmgr : I added : device "Zonet_adapter" class "network" module "kernel/drivers/net/8139too" card "10/100Mbps Ethernet Card" manfid 0x0000, 0x024c bind "Zonet_adapter" in my /etc/pcmcia/config.opts. Now insmod tries to load the module but I get : Jul 31 09:32:46 localhost kernel: 8139too Fast Ethernet driver 0.9.15c loaded Jul 31 09:32:46 localhost kernel: PCI: No IRQ known for interrupt pin A of device . Please try using pci=biosirq. Jul 31 09:32:46 localhost kernel: 8139too: : region #0 not a PIO resource, aborting Jul 31 09:32:46 localhost insmod: 8139too.o.gz: init_module: No such device Jul 31 09:32:46 localhost insmod: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters What are the options I can pass to insmod for this module, I've already tried pci=## (value given by Windows) ? By the way, how can several devices use the same IRQ : cat /proc/pci gives PCI devices found: Bus 0, device 8, function 0: Communication controller: PCI device 11c1:0420 (Lucent Microelectronics) (rev 0). IRQ 11. Master Capable. Latency=64. Min Gnt=252.Max Lat=14. Non-prefetchable 32 bit memory at 0xefffff00 [0xefffffff]. I/O at 0xff78 [0xff7f]. I/O at 0xfe00 [0xfeff]. Bus 0, device 11, function 0: CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (rev 32). IRQ 11. Master Capable. Latency=64. Min Gnt=128.Max Lat=4. Non-prefetchable 32 bit memory at 0x10000000 [0x10000fff]. Bus 0, device 11, function 1: CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (#2) (rev 32). IRQ 11. Master Capable. Latency=64. Min Gnt=128.Max Lat=4. Non-prefetchable 32 bit memory at 0x10001000 [0x10001fff]. Bus 0, device 12, function 0: Multimedia audio controller: Yamaha Corporation YMF-754 [DS-1E Audio Controller] (rev 0). IRQ 11. Master Capable. Latency=64. Min Gnt=5.Max Lat=25. Non-prefetchable 32 bit memory at 0xefff0000 [0xefff7fff]. I/O at 0xfdc0 [0xfdff]. I/O at 0xfdbc [0xfdbf]. Bus 1, device 0, function 0: VGA compatible controller: S3 Inc. 86C270-294 Savage/MX-/IX (rev 19). IRQ 11. Master Capable. Latency=248. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xf0000000 [0xf7ffffff]. Bus 20, device 0, function 0: Ethernet controller: (rev 16). Master Capable. No bursts. Min Gnt=32.Max Lat=64. All these devices seem to use the same IRQ. What about the different buses ? Thank you Julien From fluido@fluido.as Wed, 1 Aug 2001 23:19:33 +0200 Date: Wed, 1 Aug 2001 23:19:33 +0200 From: Carlo E. Prelz fluido@fluido.as Subject: [realtek] 8139too performance - can you shed some light? Hello gurus. My situation: I have to use optimally a 100MB network for transferring multimedia material from a master machine to multiple single-board computers. All computers run with kernel 2.4.7. The SBC's are powered by a NatSemi Geode CPU (Pentium-MMX class, the core is Cyrix) @ 233MHz, have 32MB of memory and are equipped with a RTL-8139C chip: --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- eth0: RealTek RTL8139 Fast Ethernet at 0xc2a14000, 00:d0:c9:34:97:73, IRQ 15 eth0: Identified 8139 chip type 'RTL-8139C' NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 41e1. --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- I equipped the master machine with two very cheap netcards, that have the same chip (equal lines at boot time), one for connecting with the world and the second for communications with the cluster of SBCs. Needing to provide the same data to all machines, I used multicast, and UDP. I wrote a simple protocol where I can easily change the packet size. At the beginning of the development, before I obtained the master machine, I developed on my home machine, talking with the SBC from a PCI ne2000-compatible card at 10Mbps, via my cheap 4-port hub. All went OK, with the slow rate that I expected would be multiplied by 10 with the upgrade to 100Mbps. I set up the master machine, and its second ethernet card has been connected to the SBC's port with a crossover cable. Normal TCP stuff (mainly ssh) works perfectly. When I tested my UDP software, I discovered with dismay that most of the packets disappeared: they were not even registered by tcpdump on the SBC. I was able to reduce the packet loss to 0 by checking the output queue on the server side with ioctl (SIOCOUTQ) and only sending when the queue size dropped under a certain level. But then, the rate of transmission was eventually comparable with what I obtained with 10Mbps. While communications is just barely able to maintain its error-free state (showing that some kind of bottleneck is reached) I can chat with the SBC via ssh observing little or no delay. I tried to: - change RX_BUF_LEN_IDX to 3 - set parameter "Use PIO instead of MMIO" in kernel config In both cases, the driver would refuse to operate. I changed max_interrupt_work from 20 to 30 and then 60, without appreciable changes. I twiddled with some parameters in /proc/sys/net, also without appreciable changes. I know that UDP has no assurance to deliver packets, so I expected to lose one packet here and there, but to lose the great majority of packets, and all this on a direct crossover cable (trying 3 different cables, too) is a bit of an anticlimax. My questions are: - Did I do some stupid, evident blunder? What can my current bottleneck be? - What throughput can I expect from a 1-way UDP traffic between two 8139C's (and eventually, to a bunch of them on a hub/switch)? - Do I need to change the hardware? I know that the 8139 chip is cheap... Thanks in advance. I can provide other info if requested. Carlo Prelz -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) From greearb@candelatech.com Wed, 01 Aug 2001 15:00:17 -0700 Date: Wed, 01 Aug 2001 15:00:17 -0700 From: Ben Greear greearb@candelatech.com Subject: [realtek] 8139too performance - can you shed some light? "Carlo E. Prelz" wrote: > > Hello gurus. > > My situation: I have to use optimally a 100MB network for transferring > multimedia material from a master machine to multiple single-board > computers. See if you can tell where the pkts are being dropped, and for what reason. Take a look at the /proc/net/dev file on all the machines, for instance. You can also increase the kernel buffers for sockets. If you do a netstat -an | grep udp, then you can see your current buffer usage, and that may give you some ideas. Do that many times because the buffers fill and un-fill quickly. Finally, you can try increasing the driver TX buffers. Check to make sure you are running at 100bt-FD too... I have some more detailed information in my FAQ on www.candelatech.com. It's primarily geared towards my application, but the general ideas may be useful to you... Btw, I've had very good luck with Intel 82557+ NICs, but they are definately more expensive... Ben > > All computers run with kernel 2.4.7. > > The SBC's are powered by a NatSemi Geode CPU (Pentium-MMX class, the > core is Cyrix) @ 233MHz, have 32MB of memory and are equipped with a > RTL-8139C chip: > > --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- > > eth0: RealTek RTL8139 Fast Ethernet at 0xc2a14000, 00:d0:c9:34:97:73, IRQ 15 > eth0: Identified 8139 chip type 'RTL-8139C' > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 2048 bind 2048) > eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 41e1. > > --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- > > I equipped the master machine with two very cheap netcards, that have the > same chip (equal lines at boot time), one for connecting with the > world and the second for communications with the cluster of SBCs. > > Needing to provide the same data to all machines, I used multicast, > and UDP. I wrote a simple protocol where I can easily change the > packet size. > > At the beginning of the development, before I obtained the master > machine, I developed on my home machine, talking with the SBC from a > PCI ne2000-compatible card at 10Mbps, via my cheap 4-port hub. All > went OK, with the slow rate that I expected would be multiplied by 10 > with the upgrade to 100Mbps. > > I set up the master machine, and its second ethernet card has been > connected to the SBC's port with a crossover cable. Normal TCP stuff > (mainly ssh) works perfectly. > > When I tested my UDP software, I discovered with dismay that most of > the packets disappeared: they were not even registered by tcpdump on > the SBC. > > I was able to reduce the packet loss to 0 by checking the output queue > on the server side with ioctl (SIOCOUTQ) and only sending when the > queue size dropped under a certain level. But then, the rate of > transmission was eventually comparable with what I obtained with > 10Mbps. > > While communications is just barely able to maintain its error-free > state (showing that some kind of bottleneck is reached) I can chat > with the SBC via ssh observing little or no delay. > > I tried to: > > - change RX_BUF_LEN_IDX to 3 > - set parameter "Use PIO instead of MMIO" in kernel config > > In both cases, the driver would refuse to operate. > > I changed max_interrupt_work from 20 to 30 and then 60, without > appreciable changes. > > I twiddled with some parameters in /proc/sys/net, also without > appreciable changes. > > I know that UDP has no assurance to deliver packets, so I expected to > lose one packet here and there, but to lose the great majority of > packets, and all this on a direct crossover cable (trying 3 different > cables, too) is a bit of an anticlimax. > > My questions are: > > - Did I do some stupid, evident blunder? What can my current > bottleneck be? > - What throughput can I expect from a 1-way UDP traffic between two > 8139C's (and eventually, to a bunch of them on a hub/switch)? > - Do I need to change the hardware? I know that the 8139 chip is > cheap... > > Thanks in advance. I can provide other info if requested. > > Carlo Prelz > > -- > * Se la Strada e la sua Virtu' non fossero state messe da parte, > * K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe > * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) > > _______________________________________________ > realtek mailing list > realtek@scyld.com > http://www.scyld.com/mailman/listinfo/realtek -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From fluido@fluido.as Thu, 2 Aug 2001 17:54:45 +0200 Date: Thu, 2 Aug 2001 17:54:45 +0200 From: Carlo E. Prelz fluido@fluido.as Subject: [realtek] 8139too performance - can you shed some light? Subject: Re: [realtek] 8139too performance - can you shed some light? Date: Wed, Aug 01, 2001 at 03:00:17PM -0700 Quoting Ben Greear (greearb@candelatech.com): > See if you can tell where the pkts are being dropped, and for what > reason. Take a look at the /proc/net/dev file on all the machines, > for instance. You can also increase the kernel buffers for sockets. If you do a > netstat -an | grep udp, then you can see your current buffer usage, > and that may give you some ideas. Do that many times because the buffers > fill and un-fill quickly. Finally, you can try increasing > the driver TX buffers. I spent the whole day exploring the problem, and I reached the conclusion that the bottleneck is in the processor. I tried the same software with a PII-400MHz and it sustained exactly the data rate I expected. I trtied to fit the SBC with 256MB of memory, but the situation did not get better. Evidently the simple processing power that is required to handle sustained 100MBps traffic is too much for a Pentium-mmx class cpu running at 233MHz. When given enough processing power, the system runs real smooth. Many thanks for dedicating some time to my problem. Happy Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) From greearb@candelatech.com Thu, 02 Aug 2001 09:05:53 -0700 Date: Thu, 02 Aug 2001 09:05:53 -0700 From: Ben Greear greearb@candelatech.com Subject: [realtek] 8139too performance - can you shed some light? "Carlo E. Prelz" wrote: > > Subject: Re: [realtek] 8139too performance - can you shed some light? > Date: Wed, Aug 01, 2001 at 03:00:17PM -0700 > > Quoting Ben Greear (greearb@candelatech.com): > > > See if you can tell where the pkts are being dropped, and for what > > reason. Take a look at the /proc/net/dev file on all the machines, > > for instance. You can also increase the kernel buffers for sockets. If you do a > > netstat -an | grep udp, then you can see your current buffer usage, > > and that may give you some ideas. Do that many times because the buffers > > fill and un-fill quickly. Finally, you can try increasing > > the driver TX buffers. > > I spent the whole day exploring the problem, and I reached the > conclusion that the bottleneck is in the processor. I tried the same > software with a PII-400MHz and it sustained exactly the data rate I > expected. I trtied to fit the SBC with 256MB of memory, but the > situation did not get better. Evidently the simple processing power > that is required to handle sustained 100MBps traffic is too much for a > Pentium-mmx class cpu running at 233MHz. When given enough processing > power, the system runs real smooth. For what it's worth, I see about 20-40% CPU usage improvement when going from the realtek to the EEPRO NICs. I'm not sure why, but it is definately noticable. That may be a cheaper design modification than re-working your CPU. That said, it takes me about 500Mhz of PII to run 80Mbps bi-directional sustained over a period of time on EEPRO 100Mbps-FD links. My program isn't the most efficient, but it has been designed with throughput in mind. You can do better if you are residing in kernel space only, too, but that may not be possible w/out major kernel hacking :) Ben > > Many thanks for dedicating some time to my problem. > > Happy > > Carlo > > -- > * Se la Strada e la sua Virtu' non fossero state messe da parte, > * K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe > * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) > > _______________________________________________ > realtek mailing list > realtek@scyld.com > http://www.scyld.com/mailman/listinfo/realtek -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From fluido@fluido.as Thu, 2 Aug 2001 18:58:52 +0200 Date: Thu, 2 Aug 2001 18:58:52 +0200 From: Carlo E. Prelz fluido@fluido.as Subject: [realtek] 8139too performance - can you shed some light? Subject: Re: [realtek] 8139too performance - can you shed some light? Date: Thu, Aug 02, 2001 at 09:05:53AM -0700 Quoting Ben Greear (greearb@candelatech.com): > For what it's worth, I see about 20-40% CPU usage improvement when going > from the realtek to the EEPRO NICs. I'm not sure why, but it is definately > noticable. That may be a cheaper design modification than re-working > your CPU. That said, it takes me about 500Mhz of PII to run 80Mbps > bi-directional sustained over a period of time on EEPRO 100Mbps-FD > links. Well, I am using a SBC, one of those cute little PC's-on-a-board with both CPU and ethernet chip soldered on-board. I could ask the people in Taiwan who produce the card to make changes for me, but I expect it would be very expensive. This is a small project... And the 400MHz PII machine was running a cheap 8138 netcard and performed just as needed... Thanks again Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) From becker@scyld.com Thu, 2 Aug 2001 13:31:29 -0400 (EDT) Date: Thu, 2 Aug 2001 13:31:29 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] 8139too performance - can you shed some light? On Thu, 2 Aug 2001, Ben Greear wrote: > "Carlo E. Prelz" wrote: > > > > Subject: Re: [realtek] 8139too performance - can you shed some light? > > Date: Wed, Aug 01, 2001 at 03:00:17PM -0700 > > > > Quoting Ben Greear (greearb@candelatech.com): > > > > > See if you can tell where the pkts are being dropped, and for what > > > reason. Take a look at the /proc/net/dev file on all the machines, > > > for instance. The number of packets dropped by the hardware, presumably because there was no room in the Rx ring, shows up in stats.rx_missed_errors The number of packets dropped because there were no skbuffs available is counted in stats.rx_dropped > > I spent the whole day exploring the problem, and I reached the > > conclusion that the bottleneck is in the processor.. > > .. Evidently the simple processing power > > that is required to handle sustained 100MBps traffic is too much for a > > Pentium-mmx class cpu running at 233MHz. >> For what it's worth, I see about 20-40% CPU usage improvement when going > from the realtek to the EEPRO NICs. I'm not sure why, but it is definately > noticable. This is easy to explain. The rtl8139 can only transmit from aligned packets. Most packets are unaligned after prepending the 14 byte Ethernet header. The rtl8139 driver must copy each packet to a bounce buffer before transmitting. On the receive side, the rtl8139 receives into a continuous ring. We can't work on the packets in the ring, so they must be copied to a receive skbuffer immediately. We copy+sum in one step, but it's still an extra copy. The eepro100 can send from and receive into skbuffers without a copy. If you know your architecture, you can likely tweak the copy code, especially the Tx copy code, to get higher performance. The driver uses memcpy(). The optimized mmx-copy is likely much faster. For those that wonder why we must immediately copy from the Rx ring rather than operating on the data without copying: consider an IP fragment that we must hold until the other fragments arrive. 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 fluido@fluido.as Fri, 3 Aug 2001 08:27:41 +0200 Date: Fri, 3 Aug 2001 08:27:41 +0200 From: Carlo E. Prelz fluido@fluido.as Subject: [realtek] 8139too performance - can you shed some light? Subject: Re: [realtek] 8139too performance - can you shed some light? Date: Thu, Aug 02, 2001 at 01:31:29PM -0400 Quoting Donald Becker (becker@scyld.com): > > > > See if you can tell where the pkts are being dropped, and for what > > > > reason. Take a look at the /proc/net/dev file on all the machines, > > > > for instance. > > The number of packets dropped by the hardware, presumably because there > was no room in the Rx ring, shows up in > stats.rx_missed_errors > The number of packets dropped because there were no skbuffs available is > counted in > stats.rx_dropped The kernel part seems to behave properly: on a period of one half minute at full speed, almost 300000 packets were sent, and only 40 were dropped and 1 was missed (data from /proc/net/dev). But my application sees almost nothing. And I have a separate thread for reading from the socket, who calls select, grabs the bytes, stores them in shared memory if needed, and goes back to select. On a faster machine, all works perfectly. Thanks for your attention! Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) From jtur@iname.com Sun, 05 Aug 2001 14:08:51 -0400 Date: Sun, 05 Aug 2001 14:08:51 -0400 From: Joan Tur jtur@iname.com Subject: [realtek] Compiling rtl8139.c Hallo! I've got a Conceptronic CON100TC pcmcia ethernet card using a Realtek 8139 chipset. I can find at www.conceptronic.net a linux driver for 2.2 kernels but i'm now using Mandrake 8 (2.4.3-20 kernel) and i need the net to work. I've downloaded rtl8139.c v.1.13 from Donald Becker together with latest pci-scan.h and kern_compat.h. When trying to compile it i get: ------------------ [root@quinipc Conceptronic.Linux]# cc -DCARDBUS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c rtl8139.c -o realtek_cb.o -I/usr/src/linux/pcmcia-cs-3.1.25/include -I/usr/src/linux/include rtl8139.c: In function `rtl8129_open': rtl8139.c:675: structure has no member named `tbusy' rtl8139.c:676: structure has no member named `interrupt' rtl8139.c:677: structure has no member named `start' rtl8139.c: In function `rtl8129_timer': rtl8139.c:777: structure has no member named `interrupt' rtl8139.c:783: structure has no member named `tbusy' rtl8139.c: In function `rtl8129_tx_timeout': rtl8139.c:910: structure has no member named `tbusy' rtl8139.c: In function `rtl8129_start_xmit': rtl8139.c:940: structure has no member named `tbusy' rtl8139.c:963: structure has no member named `tbusy' rtl8139.c:967: structure has no member named `tbusy' rtl8139.c: In function `rtl8129_interrupt': rtl8139.c:992: structure has no member named `interrupt' rtl8139.c:995: structure has no member named `interrupt' rtl8139.c:1072: structure has no member named `tbusy' rtl8139.c:1152: structure has no member named `interrupt' rtl8139.c: In function `rtl8129_close': rtl8139.c:1275: structure has no member named `start' rtl8139.c:1276: structure has no member named `tbusy' rtl8139.c: In function `rtl8129_get_stats': rtl8139.c:1354: structure has no member named `start' rtl8139.c: In function `rtl8139_detach': rtl8139.c:1527: warning: `next' might be used uninitialized in this function ------------------ Any help would be appreciated. Thanks! -- Joan Tur. Ibiza - Spain jtur@iname.com joantur@clubibosim.org Yahoo: quinir Joan.Tur.pagina.de www.ClubIbosim.org Linux: usuari registrat 190.783 From leewkb@yahoo.com Mon, 6 Aug 2001 11:15:38 -0700 (PDT) Date: Mon, 6 Aug 2001 11:15:38 -0700 (PDT) From: Bernard Lee leewkb@yahoo.com Subject: [realtek] rtl8139 driver for selected media patch --0-221812336-997121738=:86173 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi there, I came across a cosmetic enhancement for rtl8139 driver. RTL8139 users are usually provided with a DOS utility program to select default media type. e.g. rset8139.exe by Realtek to support those generic cards. This utility updates the EEPROM byte offset 0x0C, sometimes disabling auto-negotiation. Those cards will have BMCR register (MII reg 0) modified. The existing kernel 2.2.19 rtl8139 driver ignores BMCR register and reads Link-Partner register for media type. It may displays a message of "setting half-duplex" for those cards programmed with 100baseTX full-duplex... A possible fix is to check the ANE bit in BMCR register. If ANE bit is cleared, read selected media type in BMCD register. Should auto-negotiation be disabled, we don't need to do runtime auto-sense. For this purpose, rtl8129_open() is modified. The attached diff file is based on v1.07 included in Linux kernel 2.2.19. Hope it works for others too. Best Regards, Bernard Lee __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-221812336-997121738=:86173 Content-Type: application/x-unknown; name="rtl8139.c.diff" Content-Transfer-Encoding: base64 Content-Description: rtl8139.c.diff Content-Disposition: attachment; filename="rtl8139.c.diff" NzEyLDcxOGM3MTIsNzUxCjwgCQl1MTYgbWlpX3JlZzUgPSBtZGlvX3JlYWQo ZGV2LCB0cC0+cGh5c1swXSwgNSk7CjwgCQlpZiAobWlpX3JlZzUgPT0gMHhm ZmZmKQo8IAkJCTsJCQkJCS8qIE5vdCB0aGVyZSAqLwo8IAkJZWxzZSBpZiAo KG1paV9yZWc1ICYgMHgwMTAwKSA9PSAweDAxMDAKPCAJCQkJIHx8IChtaWlf cmVnNSAmIDB4MDBDMCkgPT0gMHgwMDQwKQo8IAkJCXRwLT5mdWxsX2R1cGxl eCA9IDE7CjwgCQlpZiAocnRsODEyOV9kZWJ1ZyA+IDEpCi0tLQo+ICAgICAg ICAgICAgICAgICAvKiBTb21lIGNhcmRzIG1heSBiZSBmb3JjZWQgdG8gc3Bl Y2lmaWMgbWVkaWEgdHlwZSAgICovCj4gCQkvKiBieSBjaGFuZ2luZyBkZWZh dWx0IE1TUkJNU0MgdmFsdWUgYXQgRUVQUk9NICAgICAgICovCj4gCQkvKiBi eXRlIG9mZnNldCAweDBDLiBlLmcuIHJzZXQ4MTM5LmV4ZSBzdXBwbGllZCAg ICAgICovCj4gCQkvKiBieSBSZWFsdGVrIG1heSBiZSB1c2VkIHRvIGZvcmNl IGEgMTAwYmFzZVRYIGZ1bGwtICovCj4gCQkvKiBkdXBsZXggb3BlcmF0aW9u LiBUaGUgc2VsZWN0ZWQgbWVkaWEgaXMgcmVmbGVjdGVkICovCj4gCQkvKiBh dCBCYXNpYyBNb2RlIENvbnRyb2wgUmVnaXN0ZXIuICAgICAgICAgICAgICAg ICAgICovCj4gCQkvKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICovCj4gCQkvKiBVc2VycyBhcmUgYWR2aXNl ZCB0byB1c2UgdGhpcyBmZWF0dXJlIGNhcmVmdWxseTogICovCj4gCQkvKiB1 c2UgdXRpbGl0eSBwcm9ncmFtIHN1cHBsaWVkIGJ5IGNhcmQgdmVuZG9yIGFu ZCAgICovCj4gCQkvKiBhdm9pZCB0d2Vha2luZyBFRVBST00gdmFsdWVzIHVu bGVzcyB0aGVyZSBpcyBubyAgICovCj4gCQkvKiBvdGhlciBtZWFucy4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCj4gCj4gICAg ICAgICAgICAgICAgIC8qIENoZWNrIEF1dG8tTmVnb3RpYXRpb24tRW5hYmxl IGJpdCBhdCBCYXNpYyBNb2RlCj4gCQkgICBDb250cm9sIFJlZ2lzdGVyICov Cj4gCQl1MTYgbWlpX3JlZzA7IAo+IAkJbWlpX3JlZzAgPSBtZGlvX3JlYWQo ZGV2LCB0cC0+cGh5c1swXSwgMCk7Cj4gCQlpZiAoKG1paV9yZWcwICYgMHgx MDAwKSA9PSAwKSB7Cj4gCQkgICAgLyogQXV0by1OZWdvdGlhdGlvbiBEaXNh YmxlZCAqLwo+IAkJICAgIC8qIFJlYWQgc2VsZWN0ZWQgbWVkaWEgdHlwZSBk aXJlY3RseSBhdCBCTUNSIFJlZ2lzdGVyICovCj4gCQkgICAgaWYgKChtaWlf cmVnMCAmIDB4MDEwMCkgPT0gMCkgewo+IAkJCXRwLT5mdWxsX2R1cGxleCA9 IDA7IC8qIGhhbGYtZHVwbGV4ICovCj4gCQkgICAgfSBlbHNlIHsKPiAJCQl0 cC0+ZnVsbF9kdXBsZXggPSAxOyAvKiBmdWxsLWR1cGxleCAqLwo+IAkJICAg IH0KPiAJCSAgICB0cC0+ZHVwbGV4X2xvY2sgPSAxOyAvKiBmb3Jnb3QgdGhl IGF1dG8tc2Vuc2UgZGVhbCAqLwo+IAkJICAgIGlmIChydGw4MTI5X2RlYnVn ID4gMSkKPiAJCQlwcmludGsoS0VSTl9JTkZPIiVzOiBTZXR0aW5nICVzICVz LWR1cGxleCBiYXNlZCBvbiIKPiAJCQkJICAgIiBiYXNpYyBtb2RlIGNvbnRy b2wgJTQuNHguXG4iLCBkZXYtPm5hbWUsCj4gCQkJCSAgIChtaWlfcmVnMCAm IDB4MjAwMCkgPyAiMTAwbWJwcyIgOiAiMTBtYnBzIiwKPiAJCQkJICAgdHAt PmZ1bGxfZHVwbGV4ID8gImZ1bGwiIDogImhhbGYiLCBtaWlfcmVnMCk7Cj4g CQl9IGVsc2Ugewo+IAkJICAgIC8qIEF1dG8tTmVnb3RpYXRpb24gRW5hYmxl ZCAqLwo+IAkJICAgIC8qIFJlYWQgZGV0ZWN0ZWQgbWVkaWEgdHlwZSBhdCBM aW5rIFBhcnRuZXIgUmVnaXN0ZXIgKi8KPiAJCSAgICB1MTYgbWlpX3JlZzUg PSBtZGlvX3JlYWQoZGV2LCB0cC0+cGh5c1swXSwgNSk7Cj4gCQkgICAgaWYg KG1paV9yZWc1ID09IDB4ZmZmZikKPiAgICAgCQkJOwkJCQkJLyogTm90IHRo ZXJlICovCj4gICAgIAkJICAgIGVsc2UgaWYgKChtaWlfcmVnNSAmIDB4MDEw MCkgPT0gMHgwMTAwCj4gCQkgICAgCQkgfHwgKG1paV9yZWc1ICYgMHgwMEMw KSA9PSAweDAwNDApCj4gCQkJICAgIHRwLT5mdWxsX2R1cGxleCA9IDE7Cj4g CQkgICAgaWYgKHJ0bDgxMjlfZGVidWcgPiAxKQo3MjNhNzU3Cj4gCQl9Cjc2 OWQ4MDIKPCAJaW50IG1paV9yZWc1ID0gbWRpb19yZWFkKGRldiwgdHAtPnBo eXNbMF0sIDUpOwo3NzFjODA0LDgwNgo8IAlpZiAoISB0cC0+ZHVwbGV4X2xv Y2sgICYmICBtaWlfcmVnNSAhPSAweGZmZmYpIHsKLS0tCj4gCWlmICghIHRw LT5kdXBsZXhfbG9jaykgewo+IAkgICAgdTE2IG1paV9yZWc1ID0gbWRpb19y ZWFkKGRldiwgdHAtPnBoeXNbMF0sIDUpOwo+IAkgICAgaWYgKG1paV9yZWc1 ICE9IDB4ZmZmZikgewo3NzRjODA5CjwgCQkJdHAtPmZ1bGxfZHVwbGV4ID0g ZHVwbGV4OwotLS0KPiAJCSAgICAgICAgdHAtPmZ1bGxfZHVwbGV4ID0gZHVw bGV4Owo3NzYsNzc3YzgxMSw4MTIKPCAJCQkJICAgIiBwYXJ0bmVyIGFiaWxp dHkgb2YgJTQuNHguXG4iLCBkZXYtPm5hbWUsCjwgCQkJCSAgIHRwLT5mdWxs X2R1cGxleCA/ICJmdWxsIiA6ICJoYWxmIiwgdHAtPnBoeXNbMF0sIG1paV9y ZWc1KTsKLS0tCj4gCQkJICAgICIgcGFydG5lciBhYmlsaXR5IG9mICU0LjR4 LlxuIiwgZGV2LT5uYW1lLAo+IAkJCSAgICB0cC0+ZnVsbF9kdXBsZXggPyAi ZnVsbCIgOiAiaGFsZiIsIHRwLT5waHlzWzBdLCBtaWlfcmVnNSk7Cjc4MWE4 MTcKPiAJICAgIH0K --0-221812336-997121738=:86173-- From becker@scyld.com Wed, 8 Aug 2001 03:21:39 -0400 (EDT) Date: Wed, 8 Aug 2001 03:21:39 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] Updated rtl8139-diag.c program http://www.scyld.com/diag/index.html >From the CVS log. revision 2.4 date: 2001/08/08 07:09:27; author: becker; state: Exp; lines: +179 -115 rtl8139-diag.c:v2.04 8/08/2001 Significant rewrite of EEPROM handling. Bring the EEPROM bit handling and rewrite code up to date with diag-example.c. Add the ability to write a new station address. Added an "emergency rewrite" table to attempt to recover from completely erased EEPROMs. Corrected the new_default_media bug. 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 supermoises@terra.es Sat, 11 Aug 2001 22:05:53 +0200 Date: Sat, 11 Aug 2001 22:05:53 +0200 From: Moises supermoises@terra.es Subject: [realtek] Resource temporaily unreachable Hello I'm have the next problem in start up of suse linux 6.4 with CardBus PC Card 10/100 Base-TX CardBus Ethernet PCMCIA: cardmanager is running cardmgr[69]: watching 2 sockets cardmgr[69]: Initializing socket 0 cardmgr[69]:socket 0: CardBus PC Card 10/100 Base-TX CardBus Ethernet cardmgr[69]:executing: 'insmod /lib/modules/2.2.14/pcmcia/cb_enabler.o' cardmgr[69]:executing: 'insmod /lib/modules/2.2.14/pcmcia/fethcb_cb.o' cardmgr[69]:get dev info on socket 0 failed: Resource temporaily unareachable Why ocurr this? Thanks Moisés From fuzzy@piglet.asarian.org Sun, 12 Aug 2001 19:38:01 -0400 (EDT) Date: Sun, 12 Aug 2001 19:38:01 -0400 (EDT) From: Fuzzy fuzzy@piglet.asarian.org Subject: [realtek] problems compiling the driver I'm running a 1.2.13 kernel with what started life as a slackware 3.0 distro, libc5, elf binarys. I recompiled the kernel source, but could not find any reference to modules, other then one prompt, "config-modversions". setting that prevents the kernel from compiling. I understand that current kernels ask you Y/N/M during 'make config' this one appears not to have that option. is there anyway to make the driver part of a monolithic kernel? or, is there any other way to use these cards? I have the driver for ne2K as part of the monolithic kernel it works fine. I copyed the console log for the compile, (I tried both with the "-DMODVERSIONS" and without uit). thank you... Fuzzy ++ [ -f /usr/include/linux/modversions.h ] ++ echo -DMODVERSIONS + gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c rtl8139.c -DMODVERSIONS rtl8139.c: In function `rtl8129_probe1': rtl8139.c:443: warning: implicit declaration of function `init_etherdev' rtl8139.c:443: warning: assignment makes pointer from integer without a cast rtl8139.c:529: warning: assignment from incompatible pointer type rtl8139.c: In function `rtl8129_open': rtl8139.c:697: `SA_SHIRQ' undeclared (first use this function) rtl8139.c:697: (Each undeclared identifier is reported only once rtl8139.c:697: for each function it appears in.) rtl8139.c:697: warning: passing arg 2 of `request_irq' from incompatible pointer type rtl8139.c:697: too many arguments to function `request_irq' rtl8139.c:750: warning: implicit declaration of function `virt_to_bus' rtl8139.c: In function `rtl8129_interrupt': rtl8139.c:1178: warning: unsigned int format, u32 arg (arg 3) rtl8139.c: In function `rtl8129_rx': rtl8139.c:1227: warning: unsigned int format, u32 arg (arg 3) rtl8139.c:1236: warning: unsigned int format, u32 arg (arg 3) rtl8139.c:1243: warning: unsigned int format, u32 arg (arg 3) rtl8139.c:1262: warning: implicit declaration of function `dev_alloc_skb' rtl8139.c:1262: warning: assignment makes pointer from integer without a cast rtl8139.c:1272: warning: implicit declaration of function `skb_reserve' rtl8139.c:1276: warning: implicit declaration of function `skb_put' rtl8139.c:1276: warning: passing arg 1 of `__constant_memcpy' makes pointer from integer without a cast rtl8139.c:1276: warning: passing arg 1 of `__memcpy' makes pointer from integer without a cast rtl8139.c:1278: warning: passing arg 1 of `__constant_memcpy' makes pointer from integer without a cast rtl8139.c:1278: warning: passing arg 1 of `__memcpy' makes pointer from integer without a cast rtl8139.c:1290: warning: implicit declaration of function `eth_copy_and_sum' rtl8139.c:1298: structure has no member named `protocol' rtl8139.c: In function `rtl8129_close': rtl8139.c:1344: too many arguments to function `free_irq' From BRiordan@cfund.org Mon, 13 Aug 2001 18:19:11 -0400 Date: Mon, 13 Aug 2001 18:19:11 -0400 From: Riordan, Ben BRiordan@cfund.org Subject: [realtek] Realtek 8139c - Beowulf Hello David, my 14 year old son, and I are building a Beowulf. David loves computers and he is very talented/knowledgeable about them. We read about Beowulf systems in an issue of "Wired", and we decided to build a four node system with a master unit. He has several ideas about what he wants to develop to run on it once the hardware is configured and operational, however the first set of goals for the project are: 1) learn as much as possible about building the system, 2) learn a new OS - Linux (Redhat 7.1) 3) problem-solving with his friends who are now becoming interested and involved, and 4) have fun. The nodes 1 to 4 are 1ghz AMD processors on an KVE7 motherboard with a Realtek 8139c network interface card. We ordered the nodes without cd drives only floppy drives as we anticipated using NFS to clone the nodes. We are having a devil of a time compiling the source code and installing the drivers. We are using a netboot strategy to start the process, however our 8139.o is not loading. Are there compiled versions available for Redhat 7.1 kernel 2.4.2 that we can use to install? Thank you. Ben Riordan briordan@cfund.org From becker@scyld.com Tue, 14 Aug 2001 10:27:19 -0400 (EDT) Date: Tue, 14 Aug 2001 10:27:19 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] Realtek 8139c - Beowulf On Mon, 13 Aug 2001, Riordan, Ben wrote: > David, my 14 year old son, and I are building a Beowulf. David ... > The nodes 1 to 4 are 1ghz AMD processors on an KVE7 motherboard with > a Realtek 8139c network interface card. We ordered the nodes without cd > drives only floppy drives as we anticipated using NFS to clone the nodes. The Scyld system doesn't use NFS. NFS doesn't scale well, and has bottleneck performance issues for clusters. Instead we use a single system image model with a remote execution system. The default mode is diskless, while still fully supporting local disks. You can get the unsupported basic version of Scyld Beowulf from Linux Central for just a few dollars. You should be able to configure a working cluster in about five minutes more than the time it takes to load a single machine. > We are having a devil of a time compiling the source code and installing the > drivers. We are using a netboot strategy to start the process, however our > 8139.o is not loading. Make certain the driver that you are using will recognize the specific PCI vendor ID on the cards. 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 asincero@arcadio.net Tue, 14 Aug 2001 23:00:02 -0400 Date: Tue, 14 Aug 2001 23:00:02 -0400 From: asincero@arcadio.net asincero@arcadio.net Subject: [realtek] Flashing EPROMs on a DFE-530TX+? Hello list, I have a D-Link DFE-530TX+ NIC. According to the 8139too driver, this thing uses a Realtek RTL-8139C chip. This NIC should be able to flash program a flash eprom plugged into its boot rom socket, right? But when I try to flash an Atmel AT29C256-12PC thats plugged into the boot rom socket using the rtl8139-diag utility (with libflash.c linked in) I get the following message: libflash.c:v2.03 4/19/2000 Copyright Donald Becker, becker@scyld.com This is an unknown flash chip, which cannot be programmed. Failed to load the new Flash BootROM image from file 'eb-5.0.2-mc1-rtl8139.lzrom'. rtl8139-diag.c:v2.03 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a D-Link DFE-538TX (RealTek RTL8139) adapter at 0xc800. EEPROM size test returned 6, 0x204a4 / 0x2. Would write new Default Media entry 0x0000 to offset 6, the current value is 0xe112. Hmmm, no response to the ID command, trying again.. ACKKK, this may not be a programmable Flash part! Unknown BIOS ROM ID 00 00. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. Anybody have any ideas? What would happen if I hacked libflash.c to bypass trying to identify the flash chip and tell it directly that its an Atmel AT29C256 by hardcoding it in? FWIW, I tried using the DOS Realtek flash utility, RTFLASH.EXE, I got from ftp.realtek.com.tw. However, that quickly turned out to be a deadend because when I tried to use it it said it couldn't find the ethernet card :-(. Which is kind of annoying because the DOS Realtek diagnostic and setup utility, RSET8139.EXE, is able to see and configure it just fine. Thanks in advance for any help with this. - Arcadio From becker@scyld.com Wed, 15 Aug 2001 11:00:36 -0400 (EDT) Date: Wed, 15 Aug 2001 11:00:36 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] Flashing EPROMs on a DFE-530TX+? On Tue, 14 Aug 2001 asincero@arcadio.net wrote: > uses a Realtek RTL-8139C chip. This NIC should be able to flash program a > flash eprom plugged into its boot rom socket, right? Correct, for the 'B' and 'C' parts. > But when I try to > flash an Atmel AT29C256-12PC thats plugged into the boot rom socket using > the rtl8139-diag utility (with libflash.c linked in) I get the following > message: ... > libflash.c:v2.03 4/19/2000 Copyright Donald Becker, becker@scyld.com > This is an unknown flash chip, which cannot be programmed. ... > rtl8139-diag.c:v2.03 5/15/2001 Donald Becker (becker@scyld.com) ... > Would write new Default Media entry 0x0000 to offset 6, the current value is 0xe112. Note: the recent update corrects this bug but does not change the Flash behavior. > Hmmm, no response to the ID command, trying again.. > ACKKK, this may not be a programmable Flash part! > Unknown BIOS ROM ID 00 00. Hmmm, it's not an unrecognized new part, the code isn't reading the ID at all. > Anybody have any ideas? What would happen if I hacked libflash.c to bypass > trying to identify the flash chip and tell it directly that its an Atmel > AT29C256 by hardcoding it in? It's worth a try. If the part is empty, you have no risk. If the part is already programmed, try reading the contents to see if any non-zero data can be read. > FWIW, I tried using the DOS Realtek flash utility, RTFLASH.EXE, I got from > ftp.realtek.com.tw. However, that quickly turned out to be a deadend > because when I tried to use it it said it couldn't find the ethernet card > :-(. Which is kind of annoying because the DOS Realtek diagnostic and setup > utility, RSET8139.EXE, is able to see and configure it just fine. The D-Link part has a unique PCI ID. 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 asincero@arcadio.net Wed, 15 Aug 2001 12:02:24 -0400 (EDT) Date: Wed, 15 Aug 2001 12:02:24 -0400 (EDT) From: Arcadio A. Sincero Jr. asincero@arcadio.net Subject: [realtek] Flashing EPROMs on a DFE-530TX+? On Wed, 15 Aug 2001, Donald Becker wrote: > On Tue, 14 Aug 2001 asincero@arcadio.net wrote: > > Anybody have any ideas? What would happen if I hacked libflash.c to bypass > > trying to identify the flash chip and tell it directly that its an Atmel > > AT29C256 by hardcoding it in? > It's worth a try. If the part is empty, you have no risk. > If the part is already programmed, try reading the contents to see if > any non-zero data can be read. Ok ... I went ahead and changed get_part_id() in libflash.c to simply return a 3 which would always cause the function to identify the chip as being an Atmel AT29C256. I recompiled rtl8139-diag with the modified libflash.c and then tried to flash the chip using the Etherboot ROM 'eb-5.0.2-mc1-rtl8139.lzrom' which I obtained from http://www.rom-o-matic.net (which at the time of this writing is still down unfortunately :-/). Here's what I got: libflash.c:v2.03 4/19/2000 Copyright Donald Becker, becker@scyld.comrtl8139-diag.c:v2.03 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a D-Link DFE-538TX (RealTek RTL8139) adapter at 0xc800. EEPROM size test returned 6, 0x204a4 / 0x2. Would write new Default Media entry 0x0000 to offset 6, the current value is 0xe112. Writing a block of 64 bytes at offset 0.. Flash ROM write failed at offset 0, 0x00 vs. 0x55. Failed to load the new Flash BootROM image from file 'eb-5.0.2-mc1-rtl8139.lzrom'. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. Obviously, it didn't work. Then I tried something else. I first tried to save what ever was currently in the Flash EPROM to a file by doing: rtl8139-diag -S current and this worked. I ended up with a 32k file filled with nothing but non-zero data. I then tried to load that file into the Flash EPROM by doing: rtl8139-diag -L current and it worked! Perhaps I need to convert that Etherboot ROM image to some other format first before I try to load it into the Flash EPROM? - Arcadio From asincero@arcadio.net Wed, 15 Aug 2001 12:34:35 -0400 (EDT) Date: Wed, 15 Aug 2001 12:34:35 -0400 (EDT) From: Arcadio A. Sincero Jr. asincero@arcadio.net Subject: [realtek] Flashing EPROMs on a DFE-530TX+? On Wed, 15 Aug 2001, Arcadio A. Sincero Jr. wrote: > Obviously, it didn't work. Then I tried something else. I first tried to > save what ever was currently in the Flash EPROM to a file by doing: > > rtl8139-diag -S current > > and this worked. I ended up with a 32k file filled with nothing but > non-zero data. I then tried to load that file into the Flash EPROM by > doing: Actually, this should read "a 32k file filled with nothing but zero data." Or a file consisting of nothing but ASCII 0. When I made the first reply, I took a quick look at the resulting file and noticed it wasn't empty (I just did a "more current" from the shell prompt) and thought it was non-zero data. But upon closer inspection I realized those characters I was looking at were ASCII 0. > rtl8139-diag -L current > > and it worked! Perhaps I need to convert that Etherboot ROM image to some > other format first before I try to load it into the Flash EPROM? After looking more closely at the libflash.c source, I think I know why it "worked". I think its not actually writing anything into the flash eprom. The write verification code does its thing by first reading back what it just wrote into the eprom with what it was supposed to write. Apparently, its always reading back an ASCII 0 which is why it appears to work when I try to load in "current" because its filled with nothing but ASCII 0. - Arcadio From becker@scyld.com Wed, 15 Aug 2001 15:59:58 -0400 (EDT) Date: Wed, 15 Aug 2001 15:59:58 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] Flashing EPROMs on a DFE-530TX+? On Wed, 15 Aug 2001, Arcadio A. Sincero Jr. wrote: > On Wed, 15 Aug 2001, Donald Becker wrote: > > On Tue, 14 Aug 2001 asincero@arcadio.net wrote: > > > Anybody have any ideas? What would happen if I hacked libflash.c to bypass > > > trying to identify the flash chip and tell it directly that its an Atmel > > > AT29C256 by hardcoding it in? > > It's worth a try. If the part is empty, you have no risk. > > If the part is already programmed, try reading the contents to see if > > any non-zero data can be read. > > Ok ... I went ahead and changed get_part_id() in libflash.c to simply > return a 3 which would always cause the function to identify the chip as > being an Atmel AT29C256. ... > Writing a block of 64 bytes at offset 0.. > Flash ROM write failed at offset 0, 0x00 vs. 0x55. > Failed to load the new Flash BootROM image from file 'eb-5.0.2-mc1-rtl8139.lzrom'. ... > Obviously, it didn't work. Then I tried something else. I first tried to > save what ever was currently in the Flash EPROM to a file by doing: > > rtl8139-diag -S current > > and this worked. I ended up with a 32k file filled with nothing but > non-zero data. Non-zero? Any strings, or an initial 0xaa55, that confirms you are reading valid data? > I then tried to load that file into the Flash EPROM by > doing: > > rtl8139-diag -L current > > and it worked! Perhaps I need to convert that Etherboot ROM image to some > other format first before I try to load it into the Flash EPROM? No, the boot ROM data is a direct image with no formatting. I'm guessing that somehow the part was initialized by trying to read it first. If so, we should try to track down the specific initialization problem. 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 tobi@web-arts.de Thu, 16 Aug 2001 12:50:32 +0200 Date: Thu, 16 Aug 2001 12:50:32 +0200 From: Tobias Barth tobi@web-arts.de Subject: [realtek] realtek 8100 Hi! I am looking forward to buying a new micro ATX mainboard with integrated network controller. My favourites are the ASUS A7S - VM and the MSI MS - 6378 (because I need a micro ATX board with 3 or more PCI slots). The only problem is that they have a Realtek 8100 chip on it, and I don' t know whether it will run on Linux or not. Is this a derivative of the RTL 8139 chip? Does anyone know what Linux driver will work with this chip? Ciao Tobi From becker@scyld.com Thu, 16 Aug 2001 10:33:23 -0400 (EDT) Date: Thu, 16 Aug 2001 10:33:23 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] realtek 8100 On Thu, 16 Aug 2001, Tobias Barth wrote: > The only problem is that they have a Realtek 8100 chip on it, and I don' > t know whether it will run on Linux or not. I checked http://www.realtek.com.tw/htm/products/products_4.htm and there is no listing for the 8100. I suspect they mean the 8139C, or perhaps "one of the 8130/8138/8139 series chips". 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 firefishe@chartermi.net Thu, 16 Aug 2001 11:02:39 -0400 Date: Thu, 16 Aug 2001 11:02:39 -0400 From: Charter firefishe@chartermi.net Subject: [realtek] realtek 8100 Just between thee and me, I'd stay away from the Realtek line altogether...at least from my perspective, I've had nothing but trouble with the 8139too module while using Linux-Mandrake 8.0, although I can't speak for anyone else. I'd stick with a tried and true NE2000 or NE200 clone or anything using the DEC Tulip driver (tulip.o). Just my .02c American :) Best regards, Firefishe ----- Original Message ----- From: Donald Becker To: Tobias Barth Cc: realtek mailing list Sent: Thursday, August 16, 2001 10:33 AM Subject: Re: [realtek] realtek 8100 > On Thu, 16 Aug 2001, Tobias Barth wrote: > > > The only problem is that they have a Realtek 8100 chip on it, and I don' > > t know whether it will run on Linux or not. > > I checked > http://www.realtek.com.tw/htm/products/products_4.htm > and there is no listing for the 8100. I suspect they mean the 8139C, or > perhaps "one of the 8130/8138/8139 series chips". > > 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 > > > _______________________________________________ > realtek mailing list > realtek@scyld.com > http://www.scyld.com/mailman/listinfo/realtek From tobi@web-arts.de Thu, 16 Aug 2001 18:48:45 +0200 Date: Thu, 16 Aug 2001 18:48:45 +0200 From: Tobias Barth tobi@web-arts.de Subject: [realtek] realtek 8100 Donald Becker wrote: > On Thu, 16 Aug 2001, Tobias Barth wrote: > > > The only problem is that they have a Realtek 8100 chip on it, and I don' > > t know whether it will run on Linux or not. > > I checked > http://www.realtek.com.tw/htm/products/products_4.htm > and there is no listing for the 8100. I suspect they mean the 8139C, or > perhaps "one of the 8130/8138/8139 series chips". I got an answer from realtek now: > Hi, > Thank you for your e-mail. > > RTL8100 and RTL8139 series use the same drivers. You can get the > driver > from > http://www.realtek.com.tw/htm/download/cgi/DLd1.cgi?model=RTL8139%28A%2FB%2FC%2F8130%29&type=2 > BTW, the driver has built-in in the kernel, you don't need extra > driver. Ciao Tobi From tobi@web-arts.de Thu, 16 Aug 2001 18:46:29 +0200 Date: Thu, 16 Aug 2001 18:46:29 +0200 From: Tobias Barth tobi@web-arts.de Subject: [realtek] realtek 8100 Charter wrote: > Just between thee and me, I'd stay away from the Realtek line > altogether...at least from my perspective, I've had nothing but trouble with > the 8139too module while using Linux-Mandrake 8.0, although I can't speak > for anyone else. > > I'd stick with a tried and true NE2000 or NE200 clone or anything using the > DEC Tulip driver (tulip.o). > > Just my .02c American :) I am using 2 cards with RTL8139C chip at home and about half a dozen at the university and my brother uses them in his office and I don't think they are that problematic :) Ciao Tobi P.S.: we use SuSE Linux ;) (but most of the kernels are self compiled with source trees from kernel.org). From mlauritsen@nospam.dk Fri, 17 Aug 2001 22:36:53 +0200 Date: Fri, 17 Aug 2001 22:36:53 +0200 From: Mikkel Lauritsen mlauritsen@nospam.dk Subject: [realtek] Re: Flashing EPROMs on a DFE-530TX+? Hi all, I'm new to the list, and thus I'm unable to reply to the original mail from Arcadio Sincero - I hope this works out as well. Anyway, asincero@arcadio.net wrote: > I have a D-Link DFE-530TX+ NIC. According to the 8139too driver, this > thing uses a Realtek RTL-8139C chip. This NIC should be able to flash > program a flash eprom plugged into its boot rom socket, right? But > when I try to flash an Atmel AT29C256-12PC thats plugged into the boot > rom socket using the rtl8139-diag utility (with libflash.c linked in) > I get the following message: --- snip --- > ACKKK, this may not be a programmable Flash part! > Unknown BIOS ROM ID 00 00. > Use '-a' or '-aa' to show device registers, > '-e' to show EEPROM contents, -ee for parsed contents, > or '-m' or '-mm' to show MII management registers. > > > Anybody have any ideas? Nope - this is more of a "Me too!"-post, I'm afraid. I'm trying to do the exact same thing, except for the fact that I'm using some no-name 8139C based NIC, and I get the same result. > FWIW, I tried using the DOS Realtek flash utility, RTFLASH.EXE, I got > from ftp.realtek.com.tw. However, that quickly turned out to be a > deadend because when I tried to use it it said it couldn't find the > ethernet card Well, at least here I'm able to tell of different results :-) In my case rtflash.exe is actually able to see the NIC and detect the flash prom as well. rtflash.exe doesn't support the 29C256 but it lists the manufacturer as Atmel and the device code as DC, which matches perfectly with the information from libflash.c. So, just to summarize, as opposed to libflash.c, rtflash.exe is actually able to detect the flash prom, but it won't program it. I'd actually very much like to have libflash.c detect the prom since I have a distinct feeling that my chances of getting it to support the 29C256 is much higher than with rtflash.exe. Would anybody happen to have any ideas as to why the detection fails? My first guess was that it might be due to timing problems (not that the PC is terribly fast - a 500 MHz K6), but inserting 10 us delays in the detection code made no difference. I'm going to start going through the documentation for the 8139 to see if I can find any clues as to what might be the problem, and I'm very willing to test any suggestions that you might have. Regards, Mikkel Lauritsen From mlauritsen@nospam.dk Sat, 18 Aug 2001 22:49:09 +0200 Date: Sat, 18 Aug 2001 22:49:09 +0200 From: Mikkel Lauritsen mlauritsen@nospam.dk Subject: [realtek] Re: Flashing EPROMs on a DFE-530TX+? I wrote: > I'm going to start going through the documentation for the 8139 > to see if I can find any clues as to what might be the problem, > and I'm very willing to test any suggestions that you might > have. Okay, I might not be very good at this since I'm unable to make rtl8139-diag.c and the documentation that I have downloaded from Realtek match each other. rtl8139-diag.c has the chip address for accessing the flash prom as 0x74, where the documentation says 0xD4. Also, the mask used in the rtl_flash_in function to set the OEB pin low is 0x1C0000, and judging from the docs it should be 0x160000. I might be mistaken here, and I'd very much like another opinion on this since making these changes has no effect on the inability of rtl8139-diag to detect the flash prom. Regards, Mikkel Lauritsen From daa82@columbia.edu Sun, 19 Aug 2001 13:24:43 -0400 Date: Sun, 19 Aug 2001 13:24:43 -0400 From: Denis Abramov daa82@columbia.edu Subject: [realtek] Please help installing RealTek 8139 Card w/ CardBus on RedHat 7.1 Sorry to bother you all folks, I am having a lot of problems with the Realtek 8139 card installing on RedHat Linux 7.1. The card which I am trying to install is a RealTek 10/100 Fast Ethernet with CardBus (32 bit PCMCIA card). I first saw that the kernel which comes with RedHat 7.1, namely 2.4.2 already has 8139too pre-compiled in it. Whenever I insert my card I can get an IP address from my DHCP server but that's about it - I can only ping the card's IP address and that is the only thing that I can ping on my network (can't even ping the DHCP server - weird?) apart from lo. (BTW the card works fine on a WIN2K system installed on the same computer - it's dual boot) Is it possible that the 8139too driver was compiled w/out CARDBUS support which is giving me my problems? I would like to re-compile it with CARDBUS support but that doesn't seem to work because a lot of errors are thrown (probably resulting from linux/mii.h not being there - why?). Any suggestions or ideas? So I went to try out David Becker's driver... I have been able to compile two drivers from rtl8139.c which David Becker wrote: one with the -DCARDBUS and one with regular options. The one with regular options compied fine. The one with -DCARDBUS compiled with: rtl8139.c: In function 'rtl8139_detach': rtl8139.c: warning: 'next' might be used uninitialized in this function Should I be concerned? Then as it says in the instructions for creating modules I tried to test those drivers so I tried to do "insmod pci-scan.o" and got the following errors: pci-scan.o: unresolved symbol pci_write_config_byte pci-scan.o: unresolved symbol apm_register_callback pci-scan.o: unresolved symbol kmalloc pci-scan.o: unresolved symbol pci_find_class pci-scan.o: unresolved symbol __check_region pci-scan.o: unresolved symbol pc_read_config_byte pci-scan.o: unresolved symbol pci_read_config_dword pci-scan.o: unresolved symbol apm_unregister_callback pci-scan.o: unresolved symbol __ioremap pci-scan.o: unresolved symbol pci_read_config_word pci-scan.o: unresolved symbol kfree pci-scan.o: unresolved symbol pci_set_master pci-scan.o: unresolved symbol pci_write_config_dword pci-scan.o: unresolved symbol pci_write_config_word pci-scan.o: unresolved symbol printk pci-scan.o: unresolved symbol ioport_resource When I try to do insmod "rtl8139.o" (the compiled driver w/out the CARDBUS option) I get the following errors rtl8139.o: unresolved symbol __netdev_watchdog_up rtl8139.o: unresolved symbol eth_type_trans rtl8139.o: unresolved symbol __kfree_skb rtl8139.o: unresolved symbol alloc_skb rtl8139.o: unresolved symbol init_etherdev etc. When I try to do insmod "realtek_cb.o" (the compiled driver w/ the CARDBUS option) I get the following errors: realtek_cb.o: unresolved symbol __netdev_watchdog_up realtek_cb.o: unresolved symbol eth_type_trans realtek_cb.o: unresolved symbol pcibios_read_config_byte realtek_cb.o: unresolved symbol __kfree_skb I was wondering if anyone could give me some pointers as to what I am doing wrong... Please help... If you need any other info to help me troubleshhot this please tell me... _____________________________________________ Denis Abramov daa82@columbia.edu From rboles@vt.edu Tue, 21 Aug 2001 09:32:18 -0400 Date: Tue, 21 Aug 2001 09:32:18 -0400 From: shawn rboles@vt.edu Subject: [realtek] cant insmod rtl8139.o - unresolved symbols Hello, - Background (what I have done so far): I have a DLink DFE530-TX+, which I understand uses the RTL8139B chip. The box in in question is Debian running a 2.2.17 kernel. My kernel source matches my kernel version :). I have read the documentation at www.scyld.com. I have also read through the list archives, some of which were very helpful with getting rtl8139.c to compile. I have not forgotten to get kern_compat.h, pci_scan.h and pci_scan.c. I have tried the most recent versions (from /test) of kern_compat.h and rtl8139.c. I have gotten pci-scan.c and rtl8139.c to compile without errors. No problem there. The problem is that I can not insert either into the kernel as modules. I get 'unresolved symbol' errors. Thanks for your help. I've spent 3 days on this guy and its driving me nuts. :) -shawn From r17296@email.sps.mot.com Tue, 21 Aug 2001 16:12:58 +0000 Date: Tue, 21 Aug 2001 16:12:58 +0000 From: John Traill r17296@email.sps.mot.com Subject: [realtek] GF4050C (RTL8139) Has anyone had any success with the above card. Its a 5-port 100BaseT hub which refuses to work in my x86 debian 2.2 ssytem. I've tried the driver which came with the card and downloaded the latest from www.scyld.com - Compiled as a module or directly in the kernel but without any success. Only one of the ports is detected by the kernel and it never receives any packets as report by ifconfig or by increasing the debug level. Is this card 'supported' by the 8139 driver ? -- Regards, John From becker@scyld.com Tue, 21 Aug 2001 12:02:51 -0400 (EDT) Date: Tue, 21 Aug 2001 12:02:51 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] cant insmod rtl8139.o - unresolved symbols On Tue, 21 Aug 2001, shawn wrote: > - Background (what I have done so far): > I have a DLink DFE530-TX+, which I understand uses the RTL8139B chip. > The box in in question is Debian running a 2.2.17 kernel. My kernel ... > No problem there. The problem is that I can not insert either into > the kernel as modules. I get 'unresolved symbol' errors. Your header files do not match your kernel version. Read http://www.scyld.com/network/updates.html for information on how to specific the include directory. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue, 21 Aug 2001 12:01:52 -0400 (EDT) Date: Tue, 21 Aug 2001 12:01:52 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] GF4050C (RTL8139) On Tue, 21 Aug 2001, John Traill wrote: > Subject: [realtek] GF4050C (RTL8139) > Has anyone had any success with the above card. Its a 5-port 100BaseT > hub which refuses to work in my x86 debian 2.2 ssytem. I've tried the > driver which came with the card and downloaded the latest from > www.scyld.com - Compiled as a module or directly in the kernel but > without any success. > > Only one of the ports is detected by the kernel This is likely the correct behavior. This isn't a five port card. It is a regular ethernet adapter connected to a five port repeater or switch. > and it never receives > any packets as report by ifconfig or by increasing the debug level. What is the detection message? What does 'mii-diag' or 'rtl8139-diag -am' report? 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 mikkell@knus.dk Tue, 21 Aug 2001 23:29:13 +0200 Date: Tue, 21 Aug 2001 23:29:13 +0200 From: Mikkel Lauritsen mikkell@knus.dk Subject: [realtek] Flash programming fix for rtl8139-diag Hi all, After having poked around a bit I've managed to make my generic 8139C based NIC actually program an AT29C256-120 flash prom. The patch below contains the not very documented changes that I've made. Is this the right way to go about reporting fixes like this? I haven't been able to test it with other versions of the 8139, but at least it works for me. Regards, Mikkel Lauritsen -- --- rtl8139-diag.c.orig Tue Aug 21 17:37:15 2001 +++ rtl8139-diag.c Tue Aug 21 17:41:40 2001 @@ -488,7 +488,7 @@ FlashReg=0x54, GPPinData=0x58, GPPinDir=0x59, MII_SMI=0x5A, HltClk=0x5B, MultiIntr=0x5C, TxSummary=0x60, MII_BMCR=0x62, MII_BMSR=0x64, NWayAdvert=0x66, NWayLPAR=0x68, - NWayExpansion=0x6A, FlashAccess=0x74, + NWayExpansion=0x6A, FlashAccess=0xD4, }; /* Values read from the EEPROM, and a new image to write. */ @@ -501,11 +501,15 @@ #ifdef LIBFLASH /* Support for Flash operations. */ static int rtl_flash_in(long ioaddr, int offset) { - outl(0x1C0000 | (offset & 0x1ffff), ioaddr + FlashAccess); + outl(0x1e0000, ioaddr + FlashAccess); + outl(0x60000 | (offset & 0x1ffff), ioaddr + FlashAccess); return inl(ioaddr + FlashAccess) >> 24; } static void rtl_flash_out(long ioaddr, int offset, int val) { - outl((val<<24) | 0x1a0000 | (offset & 0x1ffff), ioaddr + FlashAccess); + outl(0x1e0000, ioaddr + FlashAccess); + outl(0xe0000 | (offset & 0x1ffff), ioaddr + FlashAccess); + outl((val<<24) | 0xa0000 | (offset & 0x1ffff), ioaddr + FlashAccess); + outl(0x1c0000, ioaddr + FlashAccess); } #endif From becker@scyld.com Tue, 21 Aug 2001 19:22:07 -0400 (EDT) Date: Tue, 21 Aug 2001 19:22:07 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] Flash programming fix for rtl8139-diag On Tue, 21 Aug 2001, Mikkel Lauritsen wrote: > After having poked around a bit I've managed to make my > generic 8139C based NIC actually program an AT29C256-120 > flash prom. > > The patch below contains the not very documented changes > that I've made. Is this the right way to go about reporting > fixes like this? I haven't been able to test it with other > versions of the 8139, but at least it works for me. I suspect a difference in the chip versions. But I can't find my flash chips to test with. I'll put this change in the next rtl8139-diag version. > - NWayExpansion=0x6A, FlashAccess=0x74, > + NWayExpansion=0x6A, FlashAccess=0xD4, > static int rtl_flash_in(long ioaddr, int offset) { > - outl(0x1C0000 | (offset & 0x1ffff), ioaddr + FlashAccess); > + outl(0x1e0000, ioaddr + FlashAccess); > static void rtl_flash_out(long ioaddr, int offset, int val) { > - outl((val<<24) | 0x1a0000 | (offset & 0x1ffff), ioaddr + FlashAccess); > + outl(0x1e0000, ioaddr + FlashAccess); > + outl(0xe0000 | (offset & 0x1ffff), ioaddr + FlashAccess); > + outl((val<<24) | 0xa0000 | (offset & 0x1ffff), ioaddr + FlashAccess); > + outl(0x1c0000, ioaddr + FlashAccess); > } Hmmm, the extra flash_out() steps look a little bogus to me. Are they really needed? 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 denis.abramov@verizon.net Tue, 21 Aug 2001 20:51:02 -0400 Date: Tue, 21 Aug 2001 20:51:02 -0400 From: Denis Abramov denis.abramov@verizon.net Subject: [realtek] cant insmod rtl8139.o - unresolved symbols I have the exact same problem under RedHat 7.1... Where exactly can I find the header files for the 2.4.2 kernel running under Redhat 7.1? The update page only describes the how to incorporate the networking changes for kernels 1.2 - 2.2. Are there specific header files that I should be using with RedHat 7.1? (sorry, I'm kind of new new at this...) FYI, I have an rtl8139 chip with CardBus (your diag program doesn't specify if it is A/B/C)... > On Tue, 21 Aug 2001, shawn wrote: > > > - Background (what I have done so far): > > I have a DLink DFE530-TX+, which I understand uses the RTL8139B chip. > > The box in in question is Debian running a 2.2.17 kernel. My kernel > ... > > No problem there. The problem is that I can not insert either into > > the kernel as modules. I get 'unresolved symbol' errors. > > Your header files do not match your kernel version. > Read > http://www.scyld.com/network/updates.html > for information on how to specific the include directory. > From r17296@email.sps.mot.com Wed, 22 Aug 2001 12:03:51 +0000 Date: Wed, 22 Aug 2001 12:03:51 +0000 From: John Traill r17296@email.sps.mot.com Subject: [realtek] GF4050C (RTL8139) Donald Becker wrote: > > On Tue, 21 Aug 2001, John Traill wrote: > > > Subject: [realtek] GF4050C (RTL8139) > > Has anyone had any success with the above card. Its a 5-port 100BaseT > > hub which refuses to work in my x86 debian 2.2 ssytem. I've tried the > > driver which came with the card and downloaded the latest from > > www.scyld.com - Compiled as a module or directly in the kernel but > > without any success. > > > > Only one of the ports is detected by the kernel > > This is likely the correct behavior. This isn't a five port card. > It is a regular ethernet adapter connected to a five port repeater or > switch. > > > and it never receives > > any packets as report by ifconfig or by increasing the debug level. > > What is the detection message? > What does 'mii-diag' or 'rtl8139-diag -am' report? > > 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 As the kernel boots the card was detected as "expected" rtl8139.c:v1.13 1/9/2001 Donald Becker, becker@scyld.com. http://www.scyld.com/network/rtl8139.html eth0: RealTek RTL8139 Fast Ethernet at 0xd000, IRQ 9, 00:c0:df:04:8f:6c. linear personality registered nbd: registered device at major 43 Installing knfsd (copyright (C) 1996 okir@monad.swb.de) scsi1 : SCSI host adapter emulation for IDE ATAPI devices scsi : 2 hosts. eth0: Setting half-duplex based on auto-negotiated partner ability 0000. eth0: set_rx_mode(1042) done -- Rx config 00009400. eth0: rtl8129_open() ioaddr 0xd000 IRQ 9 GP Pins 00 half-duplex. eth0: set_rx_mode(1043) done -- Rx config 0000940e. eth0: set_rx_mode(1043) done -- Rx config 0000940e. eth0: set_rx_mode(1043) done -- Rx config 0000940e. eth0: set_rx_mode(1043) done -- Rx config 0000940e. eth0: Queued Tx packet at c35b3652 size 42 to slot 0. eth0: interrupt status=0x0004 new intstat=0x0000. eth0: interrupt status=0x0000 new intstat=0x0000. eth0: exiting interrupt, intr_status=0x0000. eth0: Media selection tick, Link partner 0000. eth0: Other registers are IntMask c07f IntStatus 0000 RxStatus fff00d00. eth0: Chip config 10 2c. eth0: Queued Tx packet at c35b3922 size 42 to slot 1. eth0: interrupt status=0x0004 new intstat=0x0000. eth0: interrupt status=0x0000 new intstat=0x0000. eth0: exiting interrupt, intr_status=0x0000. eth0: Queued Tx packet at c35b3ad2 size 42 to slot 2. eth0: interrupt status=0x0004 new intstat=0x0000. eth0: interrupt status=0x0000 new intstat=0x0000. eth0: exiting interrupt, intr_status=0x0000. eth0: Queued Tx packet at c35b3bf2 size 42 to slot 3. eth0: interrupt status=0x0004 new intstat=0x0000. eth0: interrupt status=0x0000 new intstat=0x0000. rtl8139-diag -am reports rtl8139-diag.c:v2.04 8/08/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xcc00. 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 0xcc00 0x000: 04dfc000 00006c8f 80000000 00000000 8008a03c 8008a03c 8008a03c 8008a03c 0x020: 06e58010 06e58610 06e58c10 06e59210 06e50000 0d000000 0000fff0 0000c07f 0x040: 78000400 0000940e 8dd97954 00000000 002c1000 00000000 0080c10c 00100b54 0x060: 1000f00f 05e17809 00000000 00000000 00000007 000413c0 58fab388 a438d843. No interrupt sources are pending. The chip configuration is 0x10 0x2c, MII half-duplex mode. The RTL8139 does not use a MII transceiver. It does have internal MII-compatible registers: Basic mode control register 0x7809. 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 0x0007. Receive frame error count 0x0000. -- Regards, John From becker@scyld.com Wed, 22 Aug 2001 10:53:54 -0400 (EDT) Date: Wed, 22 Aug 2001 10:53:54 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] GF4050C (RTL8139) On Wed, 22 Aug 2001, John Traill wrote: > Donald Becker wrote: > > On Tue, 21 Aug 2001, John Traill wrote: > > > Subject: [realtek] GF4050C (RTL8139) > > > Has anyone had any success with the above card. Its a 5-port 100BaseT > > > hub which refuses to work in my x86 debian 2.2 ssytem. ... > > > Only one of the ports is detected by the kernel > > > > This is likely the correct behavior. This isn't a five port card. > > It is a regular ethernet adapter connected to a five port repeater or > > switch. > > > > > and it never receives > > > any packets as report by ifconfig or by increasing the debug level. > > > > What does 'mii-diag' or 'rtl8139-diag -am' report? ... > rtl8139.c:v1.13 1/9/2001 Donald Becker, becker@scyld.com. > http://www.scyld.com/network/rtl8139.html > eth0: RealTek RTL8139 Fast Ethernet at 0xd000, IRQ 9, 00:c0:df:04:8f:6c. ... > eth0: Setting half-duplex based on auto-negotiated partner ability 0000. Hmmm, the hub section of the card must have a specialized connection. It doesn't do autonegotiation. The advertising for the card doesn't claim it's a switch, so it's likely a repeater. Thus the half duplex default setting shouldn't be a problem. What chips are on the card? RTL8139C? And what others? > eth0: Queued Tx packet at c35b3922 size 42 to slot 1. > eth0: interrupt status=0x0004 new intstat=0x0000. > eth0: interrupt status=0x0000 new intstat=0x0000. This looks normal. > rtl8139-diag.c:v2.04 8/08/2001 Donald Becker (becker@scyld.com) ... > The chip configuration is 0x10 0x2c, MII half-duplex mode. > The RTL8139 does not use a MII transceiver. > It does have internal MII-compatible registers: > Basic mode control register 0x7809. Hmmm, no link beat reported. This could indicate the problem. Either the hub chip requires a special power-up signal, or the rtl8139 requires special configuration to work without link beat. The power-up signal seems unlikely, since the hub should work even if the OS isn't loaded. You can verify this by seeing if other machines can pass traffic immediately when the host is first powered on. If the rtl8139 requires a special configuration to work without link beat, try doing mii-diag eth0 -F 100baseTx and mii-diag eth0 -F 100baseTx-FDX to see if any packets are received. The full duplex setting is wrong, but it might fool the chip into ignoring the lack of link beat. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Wed, 22 Aug 2001 12:05:30 -0400 (EDT) Date: Wed, 22 Aug 2001 12:05:30 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] GF4050C (RTL8139) On Wed, 22 Aug 2001, John Traill wrote: > > > Subject: [realtek] GF4050C (RTL8139) > > > Has anyone had any success with the above card. Its a 5-port 100BaseT > > > hub which refuses to work in my x86 debian 2.2 ssytem. I've tried the ... > rtl8139.c:v1.13 1/9/2001 Donald Becker, becker@scyld.com. > http://www.scyld.com/network/rtl8139.html > eth0: RealTek RTL8139 Fast Ethernet at 0xd000, IRQ 9, 00:c0:df:04:8f:6c. Could also please send the PCI subsystem ID for this card, found with lspci -v or cat /proc/pci or rtl8139-diag -ee If the card needs special configuration code we must uniquely identify the card to configure it automatically. 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 denis.abramov@verizon.net Wed, 22 Aug 2001 14:01:09 -0400 Date: Wed, 22 Aug 2001 14:01:09 -0400 From: Denis Abramov denis.abramov@verizon.net Subject: [realtek] cant insmod rtl8139.o - unresolved symbols Shawn, Thank you very much for your help... Followed all of your steps... This one is problematic: >You should symlink the /usr/src/linux/include/linux/modules directory > to /usr/lib/include/linux/modules or you are going to have problems > using modversions.h to compile other source. don't have anything resembling: /usr/lib/include/linux/modules Unfortunately this didn't really solve the problem... I now get compilationg errors when I do: gcc -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -Wall -Wstrict-prototypes -O6 -c pci-scan.c -o pci-scan.o -I/usr/src/linux-2.4.2/include/linux pci-scan.c: In function 'init_module': pci-scan.c: 558: warning: implicit declaration of function 'apm_register_callback' pci-scan.c: In function 'cleanup_module': pci-scan.c: 565: warning: implicit declaration of function 'apm_unregister_callback' This DOES compile using the netdriver-3.0 release Makefile provided by David Becker but doesn't 'insmod.' I'm doing all of my compiling on the contents installed by netdriver.3.0.1.src.rpm in /usr/src/redhat/BUILD/netdrivers-3.0. So I guess I'm kind of stuck between a rock and a hard place again... :-) Anyone had this problem and know how to fix it? - Denis ----- Original Message ----- From: "shawn" To: "Denis Abramov" Sent: Wednesday, August 22, 2001 9:31 AM Subject: Re: [realtek] cant insmod rtl8139.o - unresolved symbols > I eventually got my card working last night. Note that it is not a > cardbus card, but some of the following may be helpful. If it is too > basic, I apologize. > > - You need to get the kernel source with the exact same kernel that you > are currently running. Issue the `uname -a` command and check your > kernel version. There will definately be a rpm for this. Get > it and install it. > > - Your source should install somewhere like /usr/src/kernel-source-2.X.XX > or maybe /usr/src/linux. Either way, make sure that the source is > avaiable at /usr/src/linux with a symlink if necessary. > > - cd into /usr/src/linux and just run `make oldconfig`. This will do > a sort of default compilation of your kernel source. After 'make > oldconfig' is finished, edit the file /usr/src/linux/.config. Look > for the line containing MODVERSIONS. It will probably be set to off > by defautlt. Change this so that the MODVERSIONS flag is set to Y. > This modversions line needs to be set in order to generate > /usr/src/linux/include/linux/modversions.h > > - Run `make oldconfig` again, and then `make dep`. Note, this is the quick > and dirty way to get your kernel source built, I would definately not > use this kernel source for anything other than library inclusions. > > - You should symlink the /usr/src/linux/include/linux/modules directory > to /usr/lib/include/linux/modules or you are going to have problems > using modversions.h to compile other source. > > - Ok, now you have kernel source that should be useful. Try to compile > pci-scan.c and rtl8139.c using Donald's compilation instructions. > You should include the lines: -I/usr/src/linux/include/linux and > -include /usr/src/linux/include/linux/modversions.h in your compile > command. > > It might be helpful to check and see if your vendor has a linux driver. > If so it may be Donald's code anyway. But in the end, it was Donald's > code supplied by my vendor that worked. > > Good luck. > > -shawn > > On Tue, Aug 21, 2001 at 08:51:02PM -0400, Denis Abramov wrote: > > I have the exact same problem under RedHat 7.1... Where exactly can I find > > the header files for the 2.4.2 kernel running under Redhat 7.1? The update > > page only describes the how to incorporate the networking changes for > > kernels 1.2 - 2.2. Are there specific header files that I should be using > > with RedHat 7.1? (sorry, I'm kind of new new at this...) FYI, I have an > > rtl8139 chip with CardBus (your diag program doesn't specify if it is > > A/B/C)... > > > > > On Tue, 21 Aug 2001, shawn wrote: > > > > > > > - Background (what I have done so far): > > > > I have a DLink DFE530-TX+, which I understand uses the RTL8139B chip. > > > > The box in in question is Debian running a 2.2.17 kernel. My kernel > > > ... > > > > No problem there. The problem is that I can not insert either into > > > > the kernel as modules. I get 'unresolved symbol' errors. > > > > > > Your header files do not match your kernel version. > > > Read > > > http://www.scyld.com/network/updates.html > > > for information on how to specific the include directory. > > > > > > > > > _______________________________________________ > > realtek mailing list > > realtek@scyld.com > > http://www.scyld.com/mailman/listinfo/realtek > From mlauritsen@nospam.dk Wed, 22 Aug 2001 23:10:00 +0200 Date: Wed, 22 Aug 2001 23:10:00 +0200 From: Mikkel Lauritsen mlauritsen@nospam.dk Subject: [realtek] Flash programming fix for rtl8139-diag Donald Becker wrote: --- snip --- > Hmmm, the extra flash_out() steps look a little bogus to me. > Are they really needed? Well, after having tried out different versions the one below seems to work as well on my box with two steps less. The next time I hack things like this I need to cool my initial excite- ment when things start working and check whether my solution might be reduced a bit before submitting a patch :-) I've had to experiment quite heavily to get things going so I think it would be a good thing if somebody with different hardware than mine tested this out before actually adding the patch to the main code. Oh, BTW - I've been unable to match the registers listed after FlashReg (above 0x54) with those listed in the documentation for the 8139 chip. This might be due to version differences as well, I guess. Thanks a lot for your feedback and your work on this - regards, Mikkel Lauritsen -- --- rtl8139-diag.c.orig Tue Aug 21 17:37:15 2001 +++ rtl8139-diag.c Wed Aug 22 23:00:14 2001 @@ -488,7 +488,7 @@ FlashReg=0x54, GPPinData=0x58, GPPinDir=0x59, MII_SMI=0x5A, HltClk=0x5B, MultiIntr=0x5C, TxSummary=0x60, MII_BMCR=0x62, MII_BMSR=0x64, NWayAdvert=0x66, NWayLPAR=0x68, - NWayExpansion=0x6A, FlashAccess=0x74, + NWayExpansion=0x6A, FlashAccess=0xD4, }; /* Values read from the EEPROM, and a new image to write. */ @@ -501,11 +501,13 @@ #ifdef LIBFLASH /* Support for Flash operations. */ static int rtl_flash_in(long ioaddr, int offset) { - outl(0x1C0000 | (offset & 0x1ffff), ioaddr + FlashAccess); + outl(0x1e0000, ioaddr + FlashAccess); + outl(0x60000 | (offset & 0x1ffff), ioaddr + FlashAccess); return inl(ioaddr + FlashAccess) >> 24; } static void rtl_flash_out(long ioaddr, int offset, int val) { - outl((val<<24) | 0x1a0000 | (offset & 0x1ffff), ioaddr + FlashAccess); + outl(0x1e0000, ioaddr + FlashAccess); + outl((val<<24) | 0xa0000 | (offset & 0x1ffff), ioaddr + FlashAccess); } #endif From r17296@email.sps.mot.com Thu, 23 Aug 2001 12:00:44 +0000 Date: Thu, 23 Aug 2001 12:00:44 +0000 From: John Traill r17296@email.sps.mot.com Subject: [realtek] GF4050C (RTL8139) Donald Becker wrote: > > On Wed, 22 Aug 2001, John Traill wrote: > > > > > Subject: [realtek] GF4050C (RTL8139) > > > > Has anyone had any success with the above card. Its a 5-port 100BaseT > > > > hub which refuses to work in my x86 debian 2.2 ssytem. I've tried the > ... > > rtl8139.c:v1.13 1/9/2001 Donald Becker, becker@scyld.com. > > http://www.scyld.com/network/rtl8139.html > > eth0: RealTek RTL8139 Fast Ethernet at 0xd000, IRQ 9, 00:c0:df:04:8f:6c. > > Could also please send the PCI subsystem ID for this card, found with > lspci -v > or > cat /proc/pci > or > rtl8139-diag -ee > > If the card needs special configuration code we must uniquely identify > the card to configure it automatically. > > 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 As requested 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at d400 Memory at dfffef00 (32-bit, non-prefetchable) -- Regards, John From axel@rayfun.org Thu, 23 Aug 2001 14:04:15 +0200 (CEST) Date: Thu, 23 Aug 2001 14:04:15 +0200 (CEST) From: Axel axel@rayfun.org Subject: [realtek] Realtek 8139C: NETDEV WATCHDOG transmit timeout Hallo, again I get those messages, that I had as well with older 8139too in 2.4. I thought that network problem was solved with the new 8139too? I'm running kernel 2.4.8. It's connected to an ADSL Modem, so my connection gets disconnected due to the transmit timeouts.. it doesnt need so much traffic to cause it. just a little network traffic and there it goes.. Axel Aug 23 13:40:31 bello kernel: NETDEV WATCHDOG: eth1: transmit timed out Aug 23 13:40:31 bello kernel: eth1: Tx queue start entry 191 dirty entry 187. Aug 23 13:40:31 bello kernel: eth1: Tx descriptor 0 is 00002000. Aug 23 13:40:31 bello kernel: eth1: Tx descriptor 1 is 00002000. Aug 23 13:40:31 bello kernel: eth1: Tx descriptor 2 is 00002000. Aug 23 13:40:31 bello kernel: eth1: Tx descriptor 3 is 00002000. (queue head) Aug 23 13:40:31 bello kernel: eth1: Setting half-duplex based on auto-negotiated rtl8139-diag.c:v1.01 4/30/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a RealTek RTL8139 adapter at 0xf800. RealTek chip registers at 0xf800 0x000: 26843000 0000470b 80040000 40000000 9008a054 9008a03c 9008a054 9008a054 0x020: 03096000 03096600 03096c00 03097200 02f80000 0d0a0000 28702860 0000c07f 0x040: 74000600 0e00f78e f851a9c5 00000000 000d10c6 00000000 008cd108 00100000 0x060: 1000f00f 01e1782d 00000000 00000000 00000005 000f77c0 b0f243b9 7a36d743. No interrupt sources are pending. The chip configuration is 0x10 0x0d, MII half-duplex mode. 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 0x01e1. Link Partner Ability register 0x0000. Autonegotiation expansion 0x0000. Disconnects 0x0000. False carrier sense counter 0x0000. NWay test register 0x0005. Receive frame error count 0x0000. From axel@hh59.org Thu, 23 Aug 2001 14:16:57 +0200 (CEST) Date: Thu, 23 Aug 2001 14:16:57 +0200 (CEST) From: Axel Siebenwirth axel@hh59.org Subject: [realtek] Realtek 8139C: NETDEV WATCHDOG transmit timeout I got myself the latest version of rtl8139-diag and it gave me different output in the chip registers! there are different values at 0x040. axel rtl8139-diag.c:v2.04 8/08/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0xf800. 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 0xf800 0x000: 26843000 0000470b 80040000 40000000 9008a03c 9008a054 9008a054 9008a03c 0x020: 03096000 03096600 03096c00 03097200 02f80000 0d0a0000 42dc42cc 0000c07f 0x040: 74000600 0e00f78e 951264c7 00000000 000d1000 00000000 008cd108 00100000 0x060: 1000f00f 01e1782d 00000000 00000000 00000005 000f77c0 b0f243b9 7a36d743. No interrupt sources are pending. The chip configuration is 0x10 0x0d, MII half-duplex mode. 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 0x01e1. Link Partner Ability register 0x0000. Autonegotiation expansion 0x0000. Disconnects 0x0000. False carrier sense counter 0x0000. NWay test register 0x0005. Receive frame error count 0x0000. From astilley@compulan.de Thu, 23 Aug 2001 14:37:24 +0200 Date: Thu, 23 Aug 2001 14:37:24 +0200 From: compulan astilley@compulan.de Subject: [realtek] Realtek 8139C: NETDEV WATCHDOG transmit timeout Could you stop sending this to this address, it would be greatly appreciated. thank you. it has been going on for two days now, and we have no use for this information. thank you. ----- Original Message ----- From: Axel Siebenwirth To: Axel Cc: Kernel Ml ; Realtek Ml Sent: Thursday, August 23, 2001 2:16 PM Subject: Re: [realtek] Realtek 8139C: NETDEV WATCHDOG transmit timeout > I got myself the latest version of rtl8139-diag and it gave me different > output in the chip registers! there are different values at 0x040. > > axel > > rtl8139-diag.c:v2.04 8/08/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a RealTek RTL8139 adapter at 0xf800. > 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 0xf800 > 0x000: 26843000 0000470b 80040000 40000000 9008a03c 9008a054 9008a054 > 9008a03c > 0x020: 03096000 03096600 03096c00 03097200 02f80000 0d0a0000 42dc42cc > 0000c07f > 0x040: 74000600 0e00f78e 951264c7 00000000 000d1000 00000000 008cd108 > 00100000 > 0x060: 1000f00f 01e1782d 00000000 00000000 00000005 000f77c0 b0f243b9 > 7a36d743. No interrupt sources are pending. > The chip configuration is 0x10 0x0d, MII half-duplex mode. > 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 0x01e1. > Link Partner Ability register 0x0000. > Autonegotiation expansion 0x0000. > Disconnects 0x0000. > False carrier sense counter 0x0000. > NWay test register 0x0005. > Receive frame error count 0x0000. > > > > > _______________________________________________ > realtek mailing list > realtek@scyld.com > http://www.scyld.com/mailman/listinfo/realtek > From r17296@email.sps.mot.com Thu, 23 Aug 2001 14:13:32 +0000 Date: Thu, 23 Aug 2001 14:13:32 +0000 From: John Traill r17296@email.sps.mot.com Subject: [realtek] GF4050C (RTL8139) Donald Becker wrote: > > On Wed, 22 Aug 2001, John Traill wrote: > > Donald Becker wrote: > > > On Tue, 21 Aug 2001, John Traill wrote: > > > > > Subject: [realtek] GF4050C (RTL8139) > > > > Has anyone had any success with the above card. Its a 5-port 100BaseT > > > > hub which refuses to work in my x86 debian 2.2 ssytem. > ... > > > > Only one of the ports is detected by the kernel > > > > > > This is likely the correct behavior. This isn't a five port card. > > > It is a regular ethernet adapter connected to a five port repeater or > > > switch. > > > > > > > and it never receives > > > > any packets as report by ifconfig or by increasing the debug level. > > > > > > What does 'mii-diag' or 'rtl8139-diag -am' report? > ... > > rtl8139.c:v1.13 1/9/2001 Donald Becker, becker@scyld.com. > > http://www.scyld.com/network/rtl8139.html > > eth0: RealTek RTL8139 Fast Ethernet at 0xd000, IRQ 9, 00:c0:df:04:8f:6c. > ... > > eth0: Setting half-duplex based on auto-negotiated partner ability 0000. > > Hmmm, the hub section of the card must have a specialized connection. > It doesn't do autonegotiation. > > The advertising for the card doesn't claim it's a switch, so it's likely > a repeater. Thus the half duplex default setting shouldn't be a problem. > > What chips are on the card? RTL8139C? And what others? > RTL8139B TC6097P-6 TC6013B > > eth0: Queued Tx packet at c35b3922 size 42 to slot 1. > > eth0: interrupt status=0x0004 new intstat=0x0000. > > eth0: interrupt status=0x0000 new intstat=0x0000. > > This looks normal. > > > rtl8139-diag.c:v2.04 8/08/2001 Donald Becker (becker@scyld.com) > ... > > The chip configuration is 0x10 0x2c, MII half-duplex mode. > > The RTL8139 does not use a MII transceiver. > > It does have internal MII-compatible registers: > > Basic mode control register 0x7809. > > Hmmm, no link beat reported. > This could indicate the problem. > > Either the hub chip requires a special power-up signal, or the rtl8139 > requires special configuration to work without link beat. > > The power-up signal seems unlikely, since the hub should work even if > the OS isn't loaded. You can verify this by seeing if other machines > can pass traffic immediately when the host is first powered on. > After power on the card does not function as a hub. It seems dead. > If the rtl8139 requires a special configuration to work without link > beat, try doing > mii-diag eth0 -F 100baseTx > and > mii-diag eth0 -F 100baseTx-FDX > to see if any packets are received. The full duplex setting is wrong, > but it might fool the chip into ignoring the lack of link beat. > debian:/usr/src/kernel-source-2.2.19pre17/drivers/net# ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #32: 1000 782d 0000 0000 05e1 0000 0000 0000. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner does not do autonegotiation, and this transceiver type does not report the sensed link speed. End of basic transceiver information. debian:/usr/src/kernel-source-2.2.19pre17/drivers/net# ./mii-diag eth0 -F 100baseTx Setting the speed to "fixed", Control register 2100. Basic registers of MII PHY #32: 2100 780d 0000 0000 05e1 0000 0000 0000. Basic mode control register 0x2100: Auto-negotiation disabled, with Speed fixed at 100 mbps, full-duplex. You have link beat, and everything is working OK. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. debian:/usr/src/kernel-source-2.2.19pre17/drivers/net# debian:/usr/src/kernel-source-2.2.19pre17/drivers/net# ./mii-diag eth0 -F 100baseTx-FDX Invalid media advertisement '100baseTx-FDX'. Basic registers of MII PHY #32: 2100 780d 0000 0000 05e1 0000 0000 0000. Basic mode control register 0x2100: Auto-negotiation disabled, with Speed fixed at 100 mbps, full-duplex. You have link beat, and everything is working OK. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. Now I'm really confused - Any help greatly appreciated. > 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 -- Regards, John From becker@scyld.com Thu, 23 Aug 2001 10:16:15 -0400 (EDT) Date: Thu, 23 Aug 2001 10:16:15 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] GF4050C (RTL8139) On Thu, 23 Aug 2001, John Traill wrote: >> Could you also please send the PCI subsystem ID for this card.. >>00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 > Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Darn, they are using the generic EEPROM contents from Realtek. This improperly claims that it was designed/manufactured by Realtek, and means we can't distinguish it from regular rtl8139 boards. > > The advertising for the card doesn't claim it's a switch, so it's likely > > a repeater. Thus the half duplex default setting shouldn't be a problem. > > What chips are on the card? RTL8139C? And what others? > > RTL8139B > TC6097P-6 This is a Tamarack repeater. I found the datasheet on tmi.com.tw -- there is nothing unusal about it. Specifically there are no power control pins. > TC6013B How many tc6013 transceivers? Four or five? If four, then the rtl8139 has a special connection to the repeater. If five, then the rtl8139 is connected just as the external ports are. > > > Basic mode control register 0x7809. > > Hmmm, no link beat reported. > > This could indicate the problem. > Basic registers of MII PHY #32: 1000 782d 0000 0000 05e1 0000 0000 Ahhh, now we have link beat. This repeater card shouldn't require any unique setting. > > The power-up signal seems unlikely, since the hub should work even if > > the OS isn't loaded. You can verify this by seeing if other machines > > can pass traffic immediately when the host is first powered on. > > > > After power on the card does not function as a hub. It seems dead. When does the card start acting as a repeater? If the answer is "never, under Linux, but it works fine in MS Windows" then we have to figure out what turns on the repeater. If the answer is "never, even in MS Windows" then the card is broken. 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 r17296@email.sps.mot.com Thu, 23 Aug 2001 15:21:37 +0000 Date: Thu, 23 Aug 2001 15:21:37 +0000 From: John Traill r17296@email.sps.mot.com Subject: [realtek] GF4050C (RTL8139) Donald Becker wrote: > > On Thu, 23 Aug 2001, John Traill wrote: > > >> Could you also please send the PCI subsystem ID for this card.. > >>00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 > > Subsystem: Realtek Semiconductor Co., Ltd. RT8139 > > Darn, they are using the generic EEPROM contents from Realtek. This > improperly claims that it was designed/manufactured by Realtek, and > means we can't distinguish it from regular rtl8139 boards. > > > > The advertising for the card doesn't claim it's a switch, so it's likely > > > a repeater. Thus the half duplex default setting shouldn't be a problem. > > > What chips are on the card? RTL8139C? And what others? > > > > RTL8139B > > TC6097P-6 > > This is a Tamarack repeater. I found the datasheet on tmi.com.tw -- > there is nothing unusal about it. Specifically there are no power > control pins. > > > TC6013B > > How many tc6013 transceivers? Four or five? If four, then the rtl8139 has > a special connection to the repeater. If five, then the rtl8139 is > connected just as the external ports are. > There are 6 6013B devices and 5 ports ?? > > > > Basic mode control register 0x7809. > > > Hmmm, no link beat reported. > > > This could indicate the problem. > > Basic registers of MII PHY #32: 1000 782d 0000 0000 05e1 0000 0000 > > Ahhh, now we have link beat. > This repeater card shouldn't require any unique setting. > The link beat was reported by mii-diag but we never had the card working either as a repeater or receiving packets. > > > The power-up signal seems unlikely, since the hub should work even if > > > the OS isn't loaded. You can verify this by seeing if other machines > > > can pass traffic immediately when the host is first powered on. > > > > > > > After power on the card does not function as a hub. It seems dead. > > When does the card start acting as a repeater? > If the answer is "never, under Linux, but it works fine in MS Windows" > then we have to figure out what turns on the repeater. > > If the answer is "never, even in MS Windows" then the card is broken. > I'm trying to find suitable windows machine to test the card. > 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 -- Regards, John ___________________________________________________________________________ John Traill Motorola Ph. : +44 (0)1355 355494 Colvilles Road Fax. : +44 (0)1355 261790 East Kilbride G75 OTG email : johnt@burton.sps.mot.com Scotland : R17296@email.sps.mot.com [x] General Business Use [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary From william@phreaker.net Thu, 23 Aug 2001 21:42:21 +0200 Date: Thu, 23 Aug 2001 21:42:21 +0200 From: william van de velde william@phreaker.net Subject: [realtek] speed hello can someone help me? i have a realtek adapter but when i load the driver and try to download over my network the max speed is 1.23 Mbps output rtldiag Index #1: Found a RealTek RTL8139 adapter at 0xe800. RealTek chip registers at 0xe800 0x000: 5a544800 0000424a 80000000 00000000 0008a156 0008a03c 0008a03e 0008a03c 0x020: 0752e000 0752e600 0752ec00 0752f200 074b0000 0d0a0000 06e006d0 0000c07f 0x040: 74000600 0000d68e 34b29baf 00000000 006c10c6 00000000 0088c100 00100000 0x060: 1100f00f 01e1782d 000145e1 00000000 00000004 000307c8 b0f243b9 8a36df43. No interrupt sources are pending. The chip configuration is 0x10 0x6c, MII full-duplex mode. EEPROM size test returned 6, 0x204a7 / 0. but the card is working fine when i use the program (mii-tool -r) with the r from reset than i can download from my server with 10.4 Mbps now i start this program from inittab but is there a way to do this with the driver? From tobi@web-arts.de Thu, 23 Aug 2001 23:40:20 +0200 Date: Thu, 23 Aug 2001 23:40:20 +0200 From: Tobias Barth tobi@web-arts.de Subject: [realtek] RTL8100 Hi! Do You remember my post about the RTL 8100 chip? We got the mainboard (MSI - 6378) today, and the realtek drivers in the Linux kernel detect the RTL8100 chip on it as a RTL 8139 chip and work perfectly with it at 100 mbit/s. Ciao Tobi From becker@scyld.com Fri, 24 Aug 2001 01:13:05 -0400 (EDT) Date: Fri, 24 Aug 2001 01:13:05 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [realtek] speed On Thu, 23 Aug 2001, william van de velde wrote: > can someone help me? > i have a realtek adapter but when i load the driver and try to > download over my network the max speed is 1.23 Mbps Likely duplex mismatch. What does rtl8139-diag -ee report? What about statistics? Are you increasing the collision count, or seeing Rx errors? (That indicates which end has the duplex wrong.) > output rtldiag > > Index #1: Found a RealTek RTL8139 adapter at 0xe800. ... > 0x060: 1100f00f 01e1782d 000145e1 00000000 00000004 000307c8 b0f243b9 > 8a36df43. No interrupt sources are pending. Your link partner is advertising full duplex. > The chip configuration is 0x10 0x6c, MII full-duplex mode. And you are in full duplex mode. Is the chip working in this state? > but the card is working fine when i use the program (mii-tool -r) with > the r from reset That retriggers autonegotation, which sets the duplex to match. My guess is that EEPROM is set to bring the card up in forced-full-duplex mode. 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 ch@westend.com Mon, 27 Aug 2001 21:01:11 +0200 Date: Mon, 27 Aug 2001 21:01:11 +0200 From: Christian Hammers ch@westend.com Subject: [realtek] NIC boots up with 10BaseT-HD and needs manual reinit Hi On Mon, Aug 27, 2001 at 08:45:19PM +0200, Karsten Strunk wrote: > Have you found a solution for this problem yet? I've still the same problem. > I use kernel 2.4.9. No real solution. I played heavily with mii-tool, trying to force it to use the right mode and because I seemed to remember that the problems begun when after playing around with mii-debug/mii-tool. Currently the system boots and the network works although mii-tool -v says: it would be 10BaseT-HD. Because I don't trust this strange value, I added the following to my /etc/network/interfaces (Debian specific): preup modprobe -a 8139too && mii-tool -r now I imediately reset the device and after that it works *and* correctly reports a sensible autosensing value. Oh, correction. (maybe since 2.4.9?) the situation changed. It *works* but I get the following: # mii-tool -v eth0: 10 Mbit, half duplex, no link product info: vendor 00:00:00, model 0 rev 0 basic mode: 10 Mbit, half duplex basic status: no link capabilities: advertising: # mii-tool --version mii-tool.c 1.9 2000/04/28 00:56:08 (David Hinds) eth0: 10 Mbit, half duplex, no link I can force,reset,restart as much I want, nothing changes... > Thanx > Karsten bye, -christian- -- "We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the works of Shakespeare. Now, thanks to the Internet, we know this is not true." N.N. From ralph@inputplus.demon.co.uk Thu, 30 Aug 2001 23:12:52 +0100 Date: Thu, 30 Aug 2001 23:12:52 +0100 From: Ralph Corderoy ralph@inputplus.demon.co.uk Subject: [realtek] GF4050C (RTL8139) Hi, I'm writing on behalf of a non-Linux friend, Peter, who's installing Smoothwall on a PC with a GF4050C hub card. The realtek module is automatically selected but the card doesn't work. There was a recent thread on this list about this very card. http://www.scyld.com/pipermail/realtek/2001-August/001060.html > When does the card start acting as a repeater? > > If the answer is "never, under Linux, but it works fine in MS > Windows" then we have to figure out what turns on the repeater. > > If the answer is "never, even in MS Windows" then the card is > broken. Although John's card may have been broken I guess the fact that Peter's also doesn't work lessens the chances it's a hardware problem. > > How many tc6013 transceivers? Four or five? If four, then the > > rtl8139 has a special connection to the repeater. If five, then > > the rtl8139 is connected just as the external ports are. > > There are 6 6013B devices and 5 ports ?? Peter's card has the same. Given he's a hardware guy he explained that there are five 6013B transceivers to connect the five ports to the repeater (TC6097P-6) plus one more to connect the RTL8139 to the repeater. What's the current situation on getting this card to work? If there's any further information or effort that would assist we're both happy to try and help. Ralph. From ralph@inputplus.demon.co.uk Fri, 31 Aug 2001 11:50:02 +0100 Date: Fri, 31 Aug 2001 11:50:02 +0100 From: Ralph Corderoy ralph@inputplus.demon.co.uk Subject: [realtek] GF4050C (RTL8139) Hi, > If the answer is "never, under Linux, but it works fine in MS > Windows" then we have to figure out what turns on the repeater. >From the data sheet it looks like the repeater chip is non-programmable. The six Physical Layer Transceivers indicate that it is simply operating as a six port repeater with one port connected to the PCI bus and the other five going outside; therefore the repeater operation has no need of any programming. http://tmi.com.tw/Data/Spec/6097p-10.PDF I've found a suggestion that the PCI-NE2000 driver may be suitable for this card. http://lhd.zdnet.com/db/dispproduct.php3?DISP?837 http://www.scyld.com/network/ne2k-pci.html But I guess that may just be that older versions of the GF4050C used an RTL8029. Ralph. From sriram@vxl.co.in Fri, 31 Aug 2001 16:38:52 +0530 Date: Fri, 31 Aug 2001 16:38:52 +0530 From: Sriram sriram@vxl.co.in Subject: [realtek] Need RTL8019 driver This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C1323B.6B633E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hai=20 Can anyone help me in getting the ethernet driver source code for = RTL8019AS that will work on DOS. The target platform is a 16bit AM186ch = micro controller with DOS. with regards, sriram ------=_NextPart_000_0021_01C1323B.6B633E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hai
 
Can anyone help me in getting the = ethernet driver=20 source code for RTL8019AS that will work on DOS. The target = platform=20 is  a 16bit AM186ch micro controller with DOS.
 
with regards,
sriram
------=_NextPart_000_0021_01C1323B.6B633E90-- From ijgnauk@yahoo.com Fri, 31 Aug 2001 08:49:46 -0700 (PDT) Date: Fri, 31 Aug 2001 08:49:46 -0700 (PDT) From: K J Ng ijgnauk@yahoo.com Subject: [realtek] realtek_cb.o: unresolved errors Hi. I'm trying to install the realtek_cb.o driver. After managing to compile it, I get a whole bunch of unresolved symbol errors when I try to load it, such as the following /lib/modules/2.2.18pre21/net/realtek_cb.o: unresolved symbol eth_type_trans_Rd668c01b /lib/modules/2.2.18pre21/net/realtek_cb.o: unresolved symbol alloc_skb_R1fb233c8 /lib/modules/2.2.18pre21/net/realtek_cb.o: unresolved symbol __kfree_skb_Rdc1fb51d And many more. What can be the problem? I'm sure that I compiled with the correct kernel sources. I am using kernel version 2.2.18pre21, which came from an installation of Debian 2.2 (Potato). Any help will be greatly appreciated. _kj_ <-: __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com