From dsmall@home.com Sun Apr 30 19:32:48 2000 Date: Sun Apr 30 19:32:48 2000 From: Dorian Small dsmall@home.com Subject: Linksys NE 10/100 ver 4 ethernet card This is a multi-part message in MIME format. ------=_NextPart_000_007B_01BFB2C2.1A69BCC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am having trouble getting a Linksys 10/100 ethernet card to work under = slackware 7.0, kernel version 2.2.13. The linksys card is version 4 and = the chipset is labeled as Linksys. =20 =20 I have downloaded and compiled tulip 0.91g but when I load the module, = it gives the error "init_module: Device or resource busy". The /proc/pci info for the card is: Bus 0, device 8, function 0: Ethernet controller Unknown Vendor Unknown device (rev17). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. No = bursts. Min Gnt=3D255. Max Lat=3D255. I/O at 0x6000 [0x6001]. Non-prefetchable 32 bit memory at 0xf0803000 [0xf0803000]. Has anyone had any luck with this version of the linksys card? ------=_NextPart_000_007B_01BFB2C2.1A69BCC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am having trouble getting a Linksys = 10/100=20 ethernet card to work under slackware 7.0, kernel version 2.2.13. = The=20 linksys card is version 4 and the chipset is labeled as Linksys. =20

I have downloaded and compiled tulip = 0.91g but when=20 I load the module, it gives the error "init_module: Device or resource=20 busy".

The /proc/pci info for the card = is:

Bus 0, device 8, function = 0:

Ethernet controller = Unknown=20 Vendor Unknown device (rev17).

Medium devsel. Fast = back-to-back=20 capable. IRQ 10. Master Capable. No bursts. Min Gnt=3D255. Max=20 Lat=3D255.

I/O at 0x6000=20 [0x6001].

Non-prefetchable 32 = bit memory=20 at 0xf0803000 [0xf0803000].

Has anyone had any luck with this = version of the=20 linksys card?

------=_NextPart_000_007B_01BFB2C2.1A69BCC0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From romires@leca.ufrn.br Wed May 3 08:41:52 2000 Date: Wed May 3 08:41:52 2000 From: Romires C. Campelo romires@leca.ufrn.br Subject: Informations about the chip DC21140 Hi folks, I've been trying to install the U-Net protocol over Fast Ehternet but the driver isn't working correctly. I think it's necessary to make some changes in the U-Net driver. So, I need to get all kind of information about the chip DC21140. To be a little more clear, I would like to know what codes can be writen into the registers CSR*, and what those codes mean. If somebody knows about a guide, datasheet or something like that, I'll realy apreciate that information. Thanks. R.C.Campelo ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Wed May 3 19:12:04 2000 Date: Wed May 3 19:12:04 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus I haven't even subscribed yet, so I'm unsure if this message will get to the folks I hope it will get to. I just got an SMC EZCardBus 10/100 PCMCIA card and was reading some comments about it on www.deja.com that said the card should use the tulip driver. It went on to mention an edit the user made to /etc/pcmcia/config. I made the edits but the card isn't quite working yet. Is it possible to debug the driver when not connected to a network? Should I be able to at least ping myself on that interface? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Wed May 3 19:14:16 2000 Date: Wed May 3 19:14:16 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus I haven't even subscribed yet, so I'm unsure if this message will get to the folks I hope it will get to. I just got an SMC EZCardBus 10/100 PCMCIA card and was reading some comments about it on www.deja.com that said the card should use the tulip driver. It went on to mention an edit the user made to /etc/pcmcia/config. I made the edits but the card isn't quite working yet. Is it possible to debug the driver when not connected to a network? Should I be able to at least ping myself on that interface? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Wed May 3 19:17:46 2000 Date: Wed May 3 19:17:46 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus I haven't even subscribed yet, so I'm unsure if this message will get to the folks I hope it will get to. I just got an SMC EZCardBus 10/100 PCMCIA card and was reading some comments about it on www.deja.com that said the card should use the tulip driver. It went on to mention an edit the user made to /etc/pcmcia/config. I made the edits but the card isn't quite working yet. Is it possible to debug the driver when not connected to a network? Should I be able to at least ping myself on that interface? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From john@waymark.net Thu May 4 12:44:01 2000 Date: Thu May 4 12:44:01 2000 From: John Black john@waymark.net Subject: Command line. I'm not a coder, and I don't know the arguments for gcc to compile the tulip driver for SMP support. There was a description of it on www.linksys.com, the maker of the NIC I've purchased, but their site is down at this time. Could you tell me where i might find the command line? John B. Black Systems Administration Waymark Internet Services, Inc. http://www.waymark.net 972.503.1100 Option 1 john@waymark.net ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From john@waymark.net Thu May 4 12:46:12 2000 Date: Thu May 4 12:46:12 2000 From: John Black john@waymark.net Subject: Nevermind: Command line. Nevermind, I found it.. thank you anyways. John B. Black Systems Administration Waymark Internet Services, Inc. http://www.waymark.net 972.503.1100 Option 1 john@waymark.net > -----Original Message----- > From: John Black > Sent: Thursday, May 04, 2000 11:51 AM > To: 'linux-tulip@beowulf.gsfc.nasa.gov' > Subject: Command line. > > I'm not a coder, and I don't know the arguments for gcc to compile the > tulip driver for SMP support. There was a description of it on > www.linksys.com, the maker of the NIC I've purchased, but their site is > down at this time. Could you tell me where i might find the command line? > > John B. Black > Systems Administration > Waymark Internet Services, Inc. > http://www.waymark.net > 972.503.1100 Option 1 > john@waymark.net > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Thu May 4 14:11:25 2000 Date: Thu May 4 14:11:25 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus This is a multi-part message in MIME format. --------------58D8F32CFE16FA070A1F9AFF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I didn't see anything particular stand out in dmesg that looked like it recognized it. What kind of message am I looking for? It's curious that when I ifconfig eth0, the MAC address looks stupid. I attached tulip-diag's -ee output which looks closer to correct. I also attached the output of the dmesg. Maybe you will see something in there I didn't. JOHN DEGOOD wrote: > Was the card recognized at boot-up? (look in dmesg) On my Toshiba my > Xircom CardBus card wasn't recognized until I went into the BIOS setup > menu and changed the PCMCIA slot mode to CardBus, which was not the > default setting. Once I did that it was recognized and worked fine in > Linux. > > John > > Thomas Gagne wrote: > > > > I haven't even subscribed yet, so I'm unsure if this message will get to the > > folks I hope it will get to. > > > > I just got an SMC EZCardBus 10/100 PCMCIA card and was reading some comments > > about it on www.deja.com that said the card should use the tulip driver. It > > went on to mention an edit the user made to /etc/pcmcia/config. I made the > > edits but the card isn't quite working yet. > > > > Is it possible to debug the driver when not connected to a network? Should I > > be able to at least ping myself on that interface? > > ------------------------------------------------------------------- > > To unsubscribe send a message body containing "unsubscribe" > > to linux-tulip-request@beowulf.org --------------58D8F32CFE16FA070A1F9AFF Content-Type: text/plain; charset=us-ascii; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Linux version 2.2.14-5.0 (root@rocky) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Wed May 3 17:50:16 EDT 2000 Detected 497842372 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 496.44 BogoMIPS Memory: 257824k/262080k available (896k kernel code, 416k reserved, 2884k data, 60k init, 0k bigmem) Dentry hash table entries: 262144 (order 9, 2048k) Buffer cache hash table entries: 262144 (order 8, 1024k) Page cache hash table entries: 65536 (order 6, 256k) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Intel Pentium III (Coppermine) stepping 01 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch (rgooch@atnf.csiro.au) PCI: PCI BIOS revision 2.10 entry at 0xfd9ae PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 262144 bhash 65536) Initializing RT netlink socket Starting kswapd v 1.5 Detected PS/2 Mouse Port. Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A pty: 256 Unix98 ptys configured apm: BIOS version 1.2 Flags 0x03 (Driver version 1.9) Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 4096K size PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1050-0x1057, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1058-0x105f, BIOS settings: hdc:DMA, hdd:pio hda: IBM-DARA-218000, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-C2402, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: IBM-DARA-218000, 17301MB w/418kB Cache, CHS=2343/240/63 hdc: ATAPI 24X DVD-ROM drive, 128kB Cache Uniform CDROM driver Revision: 2.56 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12 raid5: measuring checksumming speed raid5: MMX detected, trying high-speed MMX checksum routines pII_mmx : 1150.620 MB/sec p5_mmx : 1222.629 MB/sec 8regs : 856.488 MB/sec 32regs : 479.298 MB/sec using fastest function: p5_mmx (1222.629 MB/sec) md.c: sizeof(mdp_super_t) = 4096 Partition check: hda: hda1 hda2 hda3 < hda5 hda6 > autodetecting RAID arrays autorun ... ... autorun DONE. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 60k freed Adding Swap: 264560k swap-space (priority -1) maestro: version 0.14 time 16:08:20 May 3 2000 PCI: Enabling bus mastering for device 00:40 maestro: Configuring ESS Maestro 2E found at IO 0x1400 IRQ 5 maestro: subvendor id: 0x009f1028 maestro: PCI power managment capability: 0x7622 maestro: AC97 Codec detected: v: 0x83847609 caps: 0x6940 pwr: 0xf maestro: 1 channels configured. CSLIP: code copyright 1989 Regents of the University of California PPP: version 2.3.7 (demand dialling) PPP line discipline registered. Linux PCMCIA Card Services 3.1.8 kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 options: [pci] [cardbus] [apm] Intel PCIC probe: TI 1225 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets host opts [0]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 32/34] host opts [1]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 35/37] ISA irqs (scanned) = 3,4,7,9,10 polling interval = 1000 ms cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x1087 cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: cb_alloc(bus 32): vendor 0x1011, device 0x0019 kmem_grow: Called nonatomically from int - size-128 ROM image dump: image 0: 0x000000-0x0001ff, signature PCIR cs: cb_config(bus 32) fn 0 bar 1: io 0x200-0x27f fn 0 bar 2: mem 0x600c0000-0x600c03ff fn 0 rom: mem 0x60080000-0x600bffff cs: cb_enable(bus 32) bridge io map 0 (flags 0x21): 0x200-0x27f bridge mem map 0 (flags 0x1): 0x60080000-0x600c0fff tulip_attach(bus 32, function 0) tulip.c:v0.91 4/14/99 becker@cesdis.gsfc.nasa.gov (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) eth0: Digital DS21143 Tulip rev 65 at 0x200, FC:00:FC:00:00:00, IRQ 3. cs: memory probe 0xa0000000-0xa0ffffff: clean. ibmtr_cs: MapMemPage: Bad offset Lucent Modem driver version 4.27.5.66 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS14 at 0x1800 (irq = 5) is a Lucent registered device ppp0 PPP BSD Compression module registered PPP Deflate Compression module registered eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbffff 8ff10008, resetting... eth0: 21140 transmit timed out, status f0260000, SIA 000010c6 ffff0001 fffbffff 8ff30008, resetting... eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbff7f 8ff10008, resetting... parport0: PC-style at 0x378 (0x778) [SPP,ECP,ECPPS2] --------------58D8F32CFE16FA070A1F9AFF Content-Type: text/plain; charset=us-ascii; name="ee.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ee.txt" tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x200. Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000000c6. EEPROM size is 6. PCI Subsystem IDs, vendor 10b8, device 8034. CardBus Information Structure at offset 0000003f. Ethernet MAC Station Address 00:E0:29:5A:AE:AD. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 21. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0886 0002. 21143 MII reset sequence is 2 words: 0886 0002. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. EEPROM contents: 10b8 8034 003f 0000 0000 0000 0000 0200 985b 0104 e000 5a29 adae 1e00 0000 0800 9501 0003 8602 0208 0200 0886 0002 7800 01e0 5000 1800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 8e6d 0000 0000 0000 e000 5a29 adae 0140 0000 0000 0000 0000 0000 0000 0000 0000 004e ID block CRC 0x5b (vs. 0x5b). Full contents CRC 0xeda5 (read as 0x004e). No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. --------------58D8F32CFE16FA070A1F9AFF-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Thu May 4 14:32:13 2000 Date: Thu May 4 14:32:13 2000 From: Donald Becker becker@scyld.com Subject: PCMCIA Driver for SMC 10/100 CardBus [[ Please use 'beowulf.org' as the list host name. ]] On Thu, 4 May 2000, Thomas Gagne wrote: > Subject: Re: PCMCIA Driver for SMC 10/100 CardBus The SMC CardBus adapter is known to work. They sent me one to test with. > It's curious that when I ifconfig eth0, the MAC address looks stupid. I > tulip.c:v0.91 4/14/99 becker@cesdis.gsfc.nasa.gov (modified by > danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) > eth0: Digital DS21143 Tulip rev 65 at 0x200, FC:00:FC:00:00:00, IRQ 3. You are correct. The driver is reading the EEPROM incorrectly. That not only causes an incorrect station address, it means that the media selection table isn't read either. The driver can make a reasonable attempt when using cards with MII transceivers, but 21143 cards using SYM transceivers usually have to have the media table exactly right. > tulip-diag's -ee output which looks closer to correct. The tulip-diag program uses EEPROM read code very similar to what is in my orginal driver versions.. > tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Digital DS21143 Tulip adapter at 0x200. ... > EEPROM size is 6. > PCI Subsystem IDs, vendor 10b8, device 8034. That looks normal. It's even a regular-sized EEPROM. > Port selection is 10mpbs-serial, full-duplex. > Transmit stopped, Receive stopped, full-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Waiting for Tx to finish'. Bad.. that usually indicates a media selection problem. I'm certain that v92, with no external modifications, works -- I just tested it. http://www.scyld.com/network/index.html ftp://scyld.com/pub/network/ Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Thu May 4 15:15:37 2000 Date: Thu May 4 15:15:37 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus Good news. I downloaded the development driver, 0.91g, rebuilt my kernel and pcmcia modules and things look better. Both lights on the transiever are on, eth0 seems to come up, and usernet seems to see activity on the device. Currently, since I'm not attached to a network I have pins 1&3, 2&6 jumped so I think that should be tricking the card into thinking it's on a network. The only think I didn't expect is, I thought I should be able to ping myself. I configured a static address for eth0 as 192.0.0.40, netmask 255.255.255.0, but when I ping the address it doesn't seem to do anything. The lights blink on the transiever's "LNK/ACT" LED but no answer to the ping. I don't know if this should concern me. I can try it with a network tomorrow at work. I'll download the 0.92 driver just in case. Heck, I never thought I'd be so happy with LEDs! Thank you (everyone) for your help. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From rgb@phy.duke.edu Thu May 4 16:41:10 2000 Date: Thu May 4 16:41:10 2000 From: Robert G. Brown rgb@phy.duke.edu Subject: Command line. On Thu, 4 May 2000, John Black wrote: > I'm not a coder, and I don't know the arguments for gcc to compile the tulip > driver for SMP support. There was a description of it on www.linksys.com, > the maker of the NIC I've purchased, but their site is down at this time. > Could you tell me where i might find the command line? Last time I looked, it was in the program itself. Look at the end of the program. rgb > > John B. Black > Systems Administration > Waymark Internet Services, Inc. > http://www.waymark.net > 972.503.1100 Option 1 > john@waymark.net > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-tulip-request@beowulf.org > Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From root@lightlink.com Thu May 4 18:20:10 2000 Date: Thu May 4 18:20:10 2000 From: Homer Wilson Smith root@lightlink.com Subject: Kingston I am unable to get Kingston KNE100TX 21143's to go into Full Dup with Cisco Switches. With the SMC cards work right with Linux 2.0.36 and v91g? Thanks Homer ------------------------------------------------------------------------ Homer Wilson Smith Clear Air, Clear Water, Art Matrix - Lightlink (607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY homer@lightlink.com Is that too much to ask? http://www.lightlink.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From fozzy@pelvoux.demon.co.uk Thu May 4 18:29:32 2000 Date: Thu May 4 18:29:32 2000 From: Steven Fosdick fozzy@pelvoux.demon.co.uk Subject: Problems with the Netgear FA310TX - Broadcasts and TX Lockup Dear List Members, Since I discovered the Netgear FA310TX I recently purchased didn't work reliably I have been looking back through the archives of this list and I'm fairly sure that the problems I am about to describe are not unique but I wonder if anyone has any ideas as to how to solve them. The configuration where the problems have been most apparent is with the follwing two PCs: Pelvoux is a 750Mhz AMD Athlon with the MSI K7-Pro motherboard (AMD chipset) and a Netgear FA310TX Rev. D2 which is based on a Netgear badged LC82C169C Bonehead is a 200Mhz AMD K6 with a First Mainboard VA-503+ and an Intel EtherExpress 16 NIC (which AFAIK is 10Mbit/sec only). These two machines are connected back to back with a cross-pinned cable. After bring up the interfaces on both machines, running tulip-diag on pelvoux reports using the MII port, half-duplex, transmitter idle and receiver waiting for packets. The first problem is that pelvoux cannot ping bonehead at this stage. After trying the ping, pelvoux (with the FA310TX) reports the correct number of packets transmitted (though each would presumably be an ARP request rather than the ICMP request) but bonehead doesn't report receiving them! Looks like it could be problem with the FA310TX sending broadcasts. If I go to bonehead and ping pelvoux it works, and after that I can ping bonehead from pelvoux, presumably because pelvoux has discovered the correct ethernet address from the incomming packets. The next test that fails is to send a long stream of TCP data from pelvoux (with the FA310TX) to bonehead. Initially I noticed this problem with FTP, but to reproduce it reliably I found the following quite effective: pelvoux$ rsh bonehead "cat > /dev/null" < /dev/zero Whilst this transfer is going on, querying eth0 on pelvoux shows an alarming large number of collisions, e.g: pelvoux:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:CC:5E:F4:3D inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:119706 errors:0 dropped:0 overruns:0 frame:0 TX packets:244596 errors:54 dropped:0 overruns:0 carrier:0 collisions:212030 txqueuelen:100 Interrupt:11 Base address:0xcc00 Not long after that pelvoux reports: May 4 21:50:58 localhost kernel: eth0: Transmit timeout using MII device. and the transfer halts. This message is repeated at intervals but nothing seems to fix the problem short of taking the interface down and bring it up again. At this stage tulip-diag reports: Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. At about the same time, bonehead reports: eth0: tx interrupt but no status After a quick look at tulip.c I found where it stops and restarts the transmitter upon getting the timeout but even after waiting 100 bus cycles between the stop and re-start the transmitter remains in state "waiting for TX to finish". The driver I have is tulip.c:v0.91g-ppc 7/16/99 which is bundled with the 2.2.14 kernel I am using. I have also tried the modified one supplied by Netgear - it fixes neither of the two problems (broadcast/ARP and the transmitter lockup). Has anyone else made any progress on these problems or have any ideas what I can try next in an effort to fix them? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Fri May 5 10:34:18 2000 Date: Fri May 5 10:34:18 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus This is a multi-part message in MIME format. --------------3DBE27938C388284AEC26F55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I installed the netdriver 2.0 RPM, the latest config.opts, and followed the instructions on the page. I rebooted without the card inserted (see dmesg.txt) then inserted the card (messages.txt). It doesn't look like cardmgr is using modprobe the way I expected it (from Don's previous instructions). Instead, it uses insmod and then complains because a couple other modules aren't present. I think I'm close, but feeling remarkably stupid at the same time. Arrgh! --------------3DBE27938C388284AEC26F55 Content-Type: text/plain; charset=us-ascii; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Linux version 2.2.14-5.0 (root@rocky) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 Thu May 4 14:50:04 EDT 2000 Detected 647204371 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 645.53 BogoMIPS Memory: 257832k/262080k available (888k kernel code, 416k reserved, 2884k data, 60k init, 0k bigmem) Dentry hash table entries: 262144 (order 9, 2048k) Buffer cache hash table entries: 262144 (order 8, 1024k) Page cache hash table entries: 65536 (order 6, 256k) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Intel Pentium III (Coppermine) stepping 01 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch (rgooch@atnf.csiro.au) PCI: PCI BIOS revision 2.10 entry at 0xfd9ae PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 262144 bhash 65536) Initializing RT netlink socket Starting kswapd v 1.5 Detected PS/2 Mouse Port. Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A pty: 256 Unix98 ptys configured apm: BIOS version 1.2 Flags 0x03 (Driver version 1.9) Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 4096K size PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1050-0x1057, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1058-0x105f, BIOS settings: hdc:DMA, hdd:pio hda: IBM-DARA-218000, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-C2402, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: IBM-DARA-218000, 17301MB w/418kB Cache, CHS=2343/240/63 hdc: ATAPI 24X DVD-ROM drive, 128kB Cache Uniform CDROM driver Revision: 2.56 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12 raid5: measuring checksumming speed raid5: MMX detected, trying high-speed MMX checksum routines pII_mmx : 1495.806 MB/sec p5_mmx : 1589.532 MB/sec 8regs : 1113.282 MB/sec 32regs : 622.935 MB/sec using fastest function: p5_mmx (1589.532 MB/sec) md.c: sizeof(mdp_super_t) = 4096 Partition check: hda: hda1 hda2 hda3 < hda5 hda6 > autodetecting RAID arrays autorun ... ... autorun DONE. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 60k freed Adding Swap: 264560k swap-space (priority -1) maestro: version 0.14 time 14:53:23 May 4 2000 PCI: Enabling bus mastering for device 00:40 maestro: Configuring ESS Maestro 2E found at IO 0x1400 IRQ 5 maestro: subvendor id: 0x009f1028 maestro: PCI power managment capability: 0x7622 maestro: AC97 Codec detected: v: 0x83847609 caps: 0x6940 pwr: 0xf maestro: 1 channels configured. CSLIP: code copyright 1989 Regents of the University of California PPP: version 2.3.7 (demand dialling) PPP line discipline registered. Linux PCMCIA Card Services 3.1.8 kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 options: [pci] [cardbus] [apm] Intel PCIC probe: TI 1225 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets host opts [0]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 32/34] host opts [1]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 35/37] ISA irqs (scanned) = 3,4,7,9,10 polling interval = 1000 ms cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x1087 cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. Lucent Modem driver version 4.27.5.66 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS14 at 0x1800 (irq = 5) is a Lucent cs: cb_alloc(bus 32): vendor 0x1011, device 0x0019 ROM image dump: image 0: 0x000000-0x0001ff, signature PCIR registered device ppp0 --------------3DBE27938C388284AEC26F55 Content-Type: text/plain; charset=us-ascii; name="messages.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages.txt" May 5 10:20:58 rocky cardmgr[435]: initializing socket 0 May 5 10:20:58 rocky cardmgr[435]: socket 0: SMC EZ CardBus 10/100 Ethernet May 5 10:20:58 rocky kernel: cs: cb_alloc(bus 32): vendor 0x1011, device 0x0019 May 5 10:20:58 rocky cardmgr[435]: executing: 'insmod /lib/modules/2.2.14-5.0/pcmcia/cb_enabler.o' May 5 10:20:58 rocky cardmgr[435]: module /lib/modules/2.2.14-5.0/pcmcia/pci-netif.o not available May 5 10:20:58 rocky cardmgr[435]: module /lib/modules/2.2.14-5.0/pcmcia/cb_shim.o not available May 5 10:20:58 rocky cardmgr[435]: module /lib/modules/2.2.14-5.0/pcmcia/tulip.o not available May 5 10:20:59 rocky cardmgr[435]: get dev info on socket 0 failed: Resource temporarily unavailable --------------3DBE27938C388284AEC26F55-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Fri May 5 10:40:38 2000 Date: Fri May 5 10:40:38 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus When I use modprobe manually I get these messages in /var/log/messages--it looks like I have to change something in the BIOS??? May 5 10:36:52 rocky kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 5 10:36:52 rocky kernel: http://www.scyld.com/network/tulip.html May 5 10:36:52 rocky kernel: The PCI BIOS has not enabled the device at 32/0! Updating PCI command 0002->0006. May 5 10:36:52 rocky kernel: eth0: Digital DS21143 Tulip rev 65 at 0xd0134000, EEPROM not present, 00:4C:69:6E:75:79, IRQ 0. May 5 10:36:52 rocky kernel: eth0: Old style EEPROM with no media selection information. May 5 10:36:52 rocky kernel: PCI: Increasing latency timer of device 20:00 to 64 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From john@casc.com Fri May 5 11:23:13 2000 Date: Fri May 5 11:23:13 2000 From: John Stoffel john@casc.com Subject: Problems with the Netgear FA310TX - Broadcasts and TX Lockup I'd like to chime in and say that I too have been disappointed with the luck I've been having with my FA310TX PCI card. I've been collecting info, but haven't had the time to actually put it into a nice format and bug report. Here's my report so far, it's pretty darn long with lots of detail about various versions of drivers I've tried. Thanks for looking at this all, John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548 john.stoffel@ascend.com - http://www.ascend.com ------------------------------------------------------------------- Hi Donald, Jeff and the rest, I've been going slowly nuts trying to get my home network to run as well as I expect it should, and I'm starting to regret getting all this NetGear stuff that I did. It consists of - Linux 2.2.15pre13, NetGear FA310-TX PCI 10/100 carc, Pentium 150, 128 Mb RAM, Matrox Millenium 4Mb, Shuttle HOT-541 motherboard. RedHat 6.1. Runs great, even if it's not the fastest. [ jfshome ] - SparCLASSIC, Linux 96 Mb Ram, RedHat 6.0, built in 10baseT ethernet. Linux 2.2.5-15. Will become my Firewall NAT box someday. [ classic ] - Windows 98, NetGear FA310-TX PCI 10/100 card, Pentium II 450, 128 Mb of Ram, Matrox G200 16Mb, MSI MS-6367 440BX motherboard. [ pc ] - At the center of it all, NetGear DS108 Dual Speed Hub. I've tried the following version of the tulip driver, with various levels of un-sucess: tulip-0.89H (old_tulip from 2.2.15pre13) tulip-0.90q tulip-0.90z tulip-0.91g (from 2.2.15pre??) tulip-0.91g-ppc (from 2.2.15pre13) Soon to try 0.92 when I get a chance, but I don't think I'm going to be lucky. Basically, when I ifconfig eth0 up, it auto-negotiates to be 100baseTx, which is great, this is exactly what the [pc] does as well. The [classic] only does 10baseT, which I expect. I hope to get a 100baseTx HME Sbus card for further testing down the line. But I can't seem to send packets to either the classic or the pc without lots of timeouts and dropped packets. The performance is pathetic. And depending on which version of the driver I use, I sometimes don't get a useable link at all, it just reports: From jfshome (192.168.1.2): Destination Host Unreachable Even though the link lights are on the hub. More annoyingly, when I ping the PC from the Classic, it works just fine, no dropped packets or anything outrageous. This is good, because I had at first thought that the hub was bad. Here's the lspci -xxxvv output from [ jfslinux ], showing that this isn't a true tulip based FA310-TX board: 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Cc: linux-tulip@beowulf.gsfc.nasa.gov Please use linux-tulip@beowulf.org as the mailing list address -- the future of the CESDIS machines is uncertain. > Subject: Re: Problems with the Netgear FA310TX - Broadcasts and TX Lockup > - Linux 2.2.15pre13, NetGear FA310-TX PCI 10/100 carc, Pentium > - At the center of it all, NetGear DS108 Dual Speed Hub. .. > I've tried the following version of the tulip driver, with various > levels of un-sucess: > > tulip-0.89H (old_tulip from 2.2.15pre13) Note that this is a heavily modified version, not the "real" 89H. > tulip-0.90q > tulip-0.90z > tulip-0.91g (from 2.2.15pre??) > tulip-0.91g-ppc (from 2.2.15pre13) These versions should work the PNIC-I, although I tested the original code not the modified versions in the kernel. ("With many eyes, all bugs are shallow. With many fingers, all bugs exist.") > Basically, when I ifconfig eth0 up, it auto-negotiates to be > 100baseTx, which is great, this is exactly what the [pc] does as ... > But I can't seem to send packets to either the classic or the pc > without lots of timeouts and dropped packets. The performance is What is the timeout message? I'm especially interested in the v92 driver message. > Here's the lspci -xxxvv output from [ jfslinux ], showing that this > isn't a true tulip based FA310-TX board: ... > 00:14.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) > Interrupt: pin A routed to IRQ 10 > Region 0: I/O ports at 6100 Grrr, it's not a "LNE100TX", it's a Lite-On PNIC. Just a nit. Everything else looks normal. > tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov > eth0: Lite-On 82c168 PNIC at 0x6100, 00 a0 cc 57 9a c1, IRQ 10. > eth0: MII transceiver found at MDIO address 1, config 3000 status 7829. No link beat, but everything else looks normal. Based on the 'mii-diag' reports below, the no-link-beat indication was just the "sticky bit" setting from boot time. > tulip.c:v0.90q 2/23/99 becker@cesdis.gsfc.nasa.gov > tulip.c:v0.90z 4/7/99 becker@cesdis.gsfc.nasa.gov > tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov > tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov All had. > eth0: Lite-On 82c168 PNIC rev 32 at 0x6100, 00:A0:CC:57:9A:C1, IRQ 10. > eth0: MII transceiver #1 config 3000 status 782d advertising 01e1. Looks normal. I traced this down to a 82c169 board produced around mid-'98. The same board layout was sold under Kingston, Linksys and Netgear brands. I tried out the Linksys version (thanks to Linksys for providing a sample!), and it works fine with tulip.c v092 in a BP6 (dual Celeron 440BX) talking to a Linksys 5 port 10/100 switch (purchased, not a sample :-<). ..And it works through a Intel InBusiness 10+100 repeater, which should be the same type of hardware you have. > Here's the log of doing an insmod, and then using the mii-diag and > tulip-diag programs from Donald Becker's web site to try and see what the > board reports on startup. The mii-diag program was compiled with the > libmii stuff as well, to make sure we got lots of debugging info. > Unfortunately, the 0.89H version of the driver didn't work quite properly > with mii-diag, so all we have is the info from the tulip-diag. The '168 chip was originally documented with only SYM transceiver support, although it had MII pins. The MII boards didn't exist in May '98 for me to have developed MII support, and when they did arrive (MII transceivers became less expensive than SYM), the chip required a work-around for a timing buglet. > mii-diag -f -a > mii-diag.c:v1.07 10/14/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > MII PHY #1 transceiver registers: > 1000 782d 0040 6212 01e1 40a1 0003 0000 Looks normal for a 10+100 bridged repeater. > I'm more than willing to try out new patches and stuff, I'd just like > to get this working properly if I can! Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From fozzy@pelvoux.demon.co.uk Fri May 5 20:14:44 2000 Date: Fri May 5 20:14:44 2000 From: Steven Fosdick fozzy@pelvoux.demon.co.uk Subject: Problems with the Netgear FA310TX - Broadcasts and TX Lockup On Fri, May 05, 2000 at 06:02:09PM -0400, Donald Becker wrote: >> tulip-0.91g-ppc (from 2.2.15pre13) > > These versions should work the PNIC-I, although I tested the original > code not the modified versions in the kernel. ("With many eyes, all bugs > are shallow. With many fingers, all bugs exist.") I tried the above tulip-0.91g-ppc and the new tulip.c:v0.92 4/17/2000 downloaded from your web site. Unfortunately 0.92 doesn't seem to fix the transmitter lock up problem I was having. The ARP/broadcast problem I reported seems to be a problem with the Intel Etherexpress 16 (ISA) at the othr end as: 1. The ARP/broadcast problem also exists when the Intel EtherExpress 16 is paired with an OEM Intel EtherExpress 100 Pro. 2. ARP works fine initiated from the FA310TX when the other end is an NE1000. The TX lockup problem does seem to be down to the FA310TX: 1. The OEM Intel EtherExpress100 Pro doesn't experience TX lockups when paired with the Intel EtherExpress 16 (ISA). 2. The FA310TX still experiences TX lockups when the other end is an NE1000. Interestingly with the OEM Intel EtherExpress100 and the FA310TX back to back (full duplex) I haven't been able to reproduce the lockup problem. > What is the timeout message? I'm especially interested in the v92 > driver message. I get (from 0.92): eth0: MII link partner 0021, negotiated 0021. eth0: Transmit timeout using MII device. As long as there is still an open TCP connection trying to send data the two messages keep appearing, and examining the TX counter with ifconfig shows that no packets have been transmitted in between two timeout messages. At this point tulip-diag reports: tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Lite-On 82c168 PNIC adapter at 0xcc00. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. 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. and mii-diag -v reports: mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html MII PHY #1 transceiver registers: 3000 782d 0040 6212 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 5000 0001 0000 0000 0000 0000 0100 0000 003c d006 0f00 ff00 002c 4000 0080 000b. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner is generating 10baseT link beat (no autonegotiation). MII PHY #1 transceiver registers: 3000 782d 0040 6212 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 5000 0000 0000 0000 0000 0000 0200 0000 003c 8006 0f00 ff00 002c 4000 0080 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. No specific information is known about this transceiver type. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. if take the card down and run tulip-diag -a I get: tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Lite-On 82c168 PNIC adapter at 0xcc00. Lite-On 82c168 PNIC chip registers at 0xcc00: 00008000 01ff0000 00450008 004fe000 004fe200 02200110 814c0000 00000000 00000000 00000000 004fe250 004fe250 00000025 00000000 00000000 10000001 00000000 00000000 f0041385 000000bf 6086782d 004fe070 06717010 0201f878 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The lspci -v command reports my card as: 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at cc00 Memory at effffe00 (32-bit, non-prefetchable) Expansion ROM at eff80000 [disabled] and your tulip driver 0.92 reports it as: eth0: Lite-On 82c168 PNIC rev 32 at 0xc88c8e00, 00:A0:CC:5E:F4:3D, IRQ 11. eth0: MII transceiver #1 config 3000 status 782d advertising 01e1. i.e. identical to John's The chip has "Netgear LC82C169C" printed on it. > Looks normal. I traced this down to a 82c169 board produced around mid-'98. > The same board layout was sold under Kingston, Linksys and Netgear brands. > > I tried out the Linksys version (thanks to Linksys for providing a sample!), > and it works fine with tulip.c v092 in a BP6 (dual Celeron 440BX) talking to > a Linksys 5 port 10/100 switch (purchased, not a sample :-<). Talking to the switch at full or half duplex? > ..And it works through a Intel InBusiness 10+100 repeater, which should be > the same type of hardware you have. Mine seems to work fine full duplex to the other 100 Mbit card I borrowed but not to either of the 10 Mbit cards (each time connected with the same cross pinned cable). It also locks up when connected to the LAN at work (which is 10 Mbit HD). It can lock up very quickly, or it can take up to half an hour of continuous transmitting. Thanks for taking the time to look at this. I hope something I have said will give you a clue what's going on. Steve Fosdick ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Fri May 5 21:48:37 2000 Date: Fri May 5 21:48:37 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: What's the difference between config and config.opt I noticed that there seems to be similar entries in both of these files. What's the difference between them? Which one should be used. For instance, I noticed in the latest network drivers RPM that the edits were made to /etc/pcmcia/config.opt and not config. Just to be consistent, I commented out the duplicates from config. Strange thing now (trying to get my EZ 10/100 cardbus to work) is that my 2.2.15 is hanging when the card is inserted, shortly after the driver is loaded. The messages in dmesg, as I mentioned in an earlier note, look like cardmgr is using the old format to insert the driver--that is, it's using insmod instead of modprobe to load tulip.o. I'll look to make sure I don't have multiple copies floating around somewhere. Comments? Suggestions? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Fri May 5 23:47:37 2000 Date: Fri May 5 23:47:37 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: tulip-diag - chip has no IRQ??? This is a multi-part message in MIME format. --------------5F44AB9A39318FD3F146FB2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What is this telling me? Everything works fine in Windows (I hate writing that). --------------5F44AB9A39318FD3F146FB2B Content-Type: text/plain; charset=us-ascii; name="diag.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diag.txt" tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0. This chip has not been assigned a valid IRQ, and will not function. This must be fixed in the PCI BIOS setup. The device driver has no way of changing the PCI IRQ settings. This chip has not been assigned a valid I/O address, and will not function. If you have warm-booted from another operating system, a complete shut-down and power cycle may restore the card to normal operation. 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. --------------5F44AB9A39318FD3F146FB2B-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Sat May 6 00:00:48 2000 Date: Sat May 6 00:00:48 2000 From: Donald Becker becker@scyld.com Subject: What's the difference between config and config.opt On Fri, 5 May 2000, Thomas Gagne wrote: > Subject: What's the difference between config and config.opt > > I noticed that there seems to be similar entries in both of these files. > What's the difference between them? Which one should be used. They both have the same data types and format. The 'config' file is the standard mapping, updated when you update your PCMCIA package. The 'config.opt' file is the local additions and special mappings. > For instance, I noticed in the latest network drivers RPM that the edits were > made to /etc/pcmcia/config.opt and not config. Just to be consistent, I > commented out the duplicates from config. The RPM doesn't install the updated table automatically. You have to do that by hand. I've just made this available as a separate file at ftp://scyld.com/pub/network/config-update The table update line is ________________ # An updated list of Tulip-based cards. device "tulip" class "network" module "cb_enabler", "pci-scan", "cb_shim", "tulip" ________________ which say "to load the tulip functionality you must load" "cb_enabler", The standard CardBus resource manager. "pci-scan" The new PCI scan code with power management. "cb_shim" The "CardBus shim" that ties cb_enabler to pci-scan "tulip" The driver itself. > Strange thing now (trying to get my EZ 10/100 cardbus to work) is that my > 2.2.15 is hanging when the card is inserted, shortly after the driver is > loaded. The messages in dmesg, as I mentioned in an earlier note, look like > cardmgr is using the old format to insert the driver--that is, it's using > insmod instead of modprobe to load tulip.o. I'll look to make sure I don't > have multiple copies floating around somewhere. There seems to be a problem with the SMC card -- I managed to hang my machine twice while inserting and ejecting it. This doesn't happen with the other Tulip CardBus cards, so there must be something in the media table causing this behavior. I'll spend some more time tonight on the problem. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Sat May 6 01:10:53 2000 Date: Sat May 6 01:10:53 2000 From: Donald Becker becker@scyld.com Subject: tulip-diag - chip has no IRQ??? On Fri, 5 May 2000, Thomas Gagne wrote: > What is this telling me? Everything works fine in Windows (I hate writing > that). > >tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Digital DS21143 Tulip adapter at 0. > This chip has not been assigned a valid IRQ, and will not function. > This must be fixed in the PCI BIOS setup. The device driver has no way > of changing the PCI IRQ settings. > This chip has not been assigned a valid I/O address, and will not function. > If you have warm-booted from another operating system, a complete > shut-down and power cycle may restore the card to normal operation. For a CardBus card this is telling you that the PCMCIA code did not assign resources to the card, presumably because it didn't have IRQs and memory space to assign. it was confused because of a memory or IRQ leak. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From homer@lightlink.com Sat May 6 18:47:42 2000 Date: Sat May 6 18:47:42 2000 From: Homer Wilson Smith homer@lightlink.com Subject: Digital Tulip Design > > Do we have a driver yet that will do 10 meg full duplex on these > > babies? > > Yes, both the 91g and 92 versions should work fine. I have not been able to get either to work. Linux 2.0.36 Kingston KNE100TX 21143 Thanks Homer ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From atterer@informatik.tu-muenchen.de Sun May 7 12:41:32 2000 Date: Sun May 7 12:41:32 2000 From: Richard Atterer atterer@informatik.tu-muenchen.de Subject: PCMCIA Driver for SMC 10/100 CardBus On Thu, May 04, 2000 at 11:01:42PM +0000, Donald Becker wrote: > > Subject: Re: PCMCIA Driver for SMC 10/100 CardBus > > The SMC CardBus adapter is known to work. > They sent me one to test with. When did they send it? I'm asking because they seem to have changed the design of the card without also changing the name or model number. (The PCMCIA ID *has* changed, though.) v0.91g most definitely doesn't work with it, and IIRC neither does 0.91x. > > Port selection is 10mpbs-serial, full-duplex. > > Transmit stopped, Receive stopped, full-duplex. > > The Rx process state is 'Stopped'. > > The Tx process state is 'Waiting for Tx to finish'. Only looks too familiar... :-( > Bad.. that usually indicates a media selection problem. > > I'm certain that v92, with no external modifications, works -- I just tested > it. Sounds good - I'll try it! Cheers, Richard -- __ _ |_) /| Richard Atterer (currently at Queen's University, Belfast, NI) | \/�| http://www.in.tum.de/~atterer/ � �` � ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From chris.martin2@btinternet.com Sun May 7 13:56:13 2000 Date: Sun May 7 13:56:13 2000 From: Chris Martin chris.martin2@btinternet.com Subject: Linux 2.2.14 and FA310TA cards On 26 Apr 2000, Chris Martin wrote: > I have two FA310TX cards, one in a 150 MHz Pentium machine and the > other in a 600 MHz dual Pentium III machine linked by an FE104 hub (a > Netgear FB104 starter kit). ... > No problems were reported when I tested the connection under DOS using > the DIAG.EXE on the diagnostic disk. ... > 53 packets transmitted, 21 packets received, 60% packet loss > round-trip min/avg/max = 0.3/0.3/0.3 ms > While pinging the slow machine from the fast machine shows > > 51 packets transmitted, 23 packets received, +10 corrupted, 54% packet loss > round-trip min/avg/max = 0.2/0.2/0.2 ms > The corrupted packets show an output like > > 64 bytes from 192.168.1.1: icmp_seq=40 ttl=255 time=0.2 ms (BAD CHECKSUM!) Donald> So you are getting corruption either in a switch (but you have Donald> a repeater, so rule that out) or on the PCI bus or memory Donald> system. I have now tested it further and, using Tom Oeser's tomsrtbt (2.0.37, tulip.c 0.90 10/20/98) the packet loss rate drops from 50% to 20% on both machines but the corruption remains on the fast one. However, replacing the Netgear hub with a 3Com 10mbit hub cures the problem completely -- ping is 0% packet loss and ftp gives ~824 Kb/s. Does this mean that the Netgear hub is faulty or does it just mean that the cards work OK at the lower speed? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Sun May 7 19:17:23 2000 Date: Sun May 7 19:17:23 2000 From: Donald Becker becker@scyld.com Subject: Linux 2.2.14 and FA310TA cards On 7 May 2000, Chris Martin wrote: > > 64 bytes from 192.168.1.1: icmp_seq=40 ttl=255 time=0.2 ms (BAD CHECKSUM!) > > Donald> So you are getting corruption either in a switch (but you have > Donald> a repeater, so rule that out) or on the PCI bus or memory > Donald> system. .. > However, replacing the Netgear hub with a 3Com 10mbit hub cures the > problem completely -- ping is 0% packet loss and ftp gives ~824 Kb/s. > > Does this mean that the Netgear hub is faulty or does it just mean > that the cards work OK at the lower speed? Is this a 10+100 repeater, or a switch? If so, it's bad. If it's a normal "dumb" repeater, it would be extremely unusual to have it corrupt packet data and leave a good CRC. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Sun May 7 19:59:01 2000 Date: Sun May 7 19:59:01 2000 From: Donald Becker becker@scyld.com Subject: Digital Tulip Design On Sat, 6 May 2000, Homer Wilson Smith wrote: > > > Do we have a driver yet that will do 10 meg full duplex on these > > > babies? > > > > Yes, both the 91g and 92 versions should work fine. > > I have not been able to get either to work. > > Linux 2.0.36 Kingston KNE100TX 21143 I just tested the following configuration tulip.c v92, as distributed. a Kingston KNE100TX 21143-PD Seeq 80220 MII transceiver [[ This board has a label "Do not remove this sample from engineering lab";-> I guess someone at Kingston is now in trouble.. ]] on a BP-6 Celeron 440BX chipset It works fine with all media types, both autonegotiated and forced. ________________ tulip.c:v0.92 4/17/2000 Written by Donald Becker http://www.scyld.com/network/tulip.html ... eth1: Digital DS21143 Tulip rev 65 at 0x88021000, 00:C0:F0:3B:00:02, IRQ 10. eth1: EEPROM default media type Autosense. eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth1: MII transceiver #1 config 3000 status 7809 advertising 01e1. ... eth1: Setting full-duplex based on MII #1 link partner capability of 41e1. eth1: Setting half-duplex based on MII #1 link partner capability of 4021. [[ Other messages omitted. ]] ________________ I claim that you have some other problem. [[ Grrrr. This took me 30 minutes to do, due to the damn APIC bugs. I finally gave up and just booted with "noapic". ]] Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Sun May 7 20:01:18 2000 Date: Sun May 7 20:01:18 2000 From: Donald Becker becker@scyld.com Subject: PCMCIA Driver for SMC 10/100 CardBus On Sun, 7 May 2000, Richard Atterer wrote: > > > Subject: Re: PCMCIA Driver for SMC 10/100 CardBus > > > > The SMC CardBus adapter is known to work. > > They sent me one to test with. > > When did they send it? I'm asking because they seem to have changed > the design of the card without also changing the name or model > number. (The PCMCIA ID *has* changed, though.) v0.91g most definitely > doesn't work with it, and IIRC neither does 0.91x. Hmmm, probably a year or so ago. I can't find the paperwork on it. Load with debug=7 and send the output... Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From homer@lightlink.com Sun May 7 20:01:59 2000 Date: Sun May 7 20:01:59 2000 From: Homer Wilson Smith homer@lightlink.com Subject: Digital Tulip Design HI Donald, thanks for your work, this is good news. I was not able to get v92g to run in linux 2.0.36. Homer superoot jane/usr/local/main/tulip: insmod tulip.o pci_drv_register: wrong version or undefined pci_drv_unregister: wrong version or undefined Loading failed! The module symbols (from linux-2.0.36) don't match your linux-2.0.36 ------------------------------------------------------------------------ Homer Wilson Smith Clear Air, Clear Water, Art Matrix - Lightlink (607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY homer@lightlink.com Is that too much to ask? http://www.lightlink.com On Sun, 7 May 2000, Donald Becker wrote: > On Sat, 6 May 2000, Homer Wilson Smith wrote: > > > > > Do we have a driver yet that will do 10 meg full duplex on these > > > > babies? > > > > > > Yes, both the 91g and 92 versions should work fine. > > > > I have not been able to get either to work. > > > > Linux 2.0.36 Kingston KNE100TX 21143 > > I just tested the following configuration > tulip.c v92, as distributed. > a Kingston KNE100TX > 21143-PD > Seeq 80220 MII transceiver > [[ This board has a label "Do not remove this sample from engineering > lab";-> I guess someone at Kingston is now in trouble.. ]] > on a BP-6 > Celeron > 440BX chipset > > It works fine with all media types, both autonegotiated and forced. > > ________________ > tulip.c:v0.92 4/17/2000 Written by Donald Becker > http://www.scyld.com/network/tulip.html > ... > eth1: Digital DS21143 Tulip rev 65 at 0x88021000, 00:C0:F0:3B:00:02, IRQ 10. > eth1: EEPROM default media type Autosense. > eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. > eth1: MII transceiver #1 config 3000 status 7809 advertising 01e1. > ... > eth1: Setting full-duplex based on MII #1 link partner capability of 41e1. > eth1: Setting half-duplex based on MII #1 link partner capability of 4021. > > [[ Other messages omitted. ]] > ________________ > > I claim that you have some other problem. > > [[ Grrrr. This took me 30 minutes to do, due to the damn APIC bugs. I > finally gave up and just booted with "noapic". ]] > > Donald Becker becker@scyld.com > Scyld Computing Corporation > 410 Severn Ave. Suite 210 > Annapolis MD 21403 > > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Mon May 8 03:06:28 2000 Date: Mon May 8 03:06:28 2000 From: Donald Becker becker@scyld.com Subject: Digital Tulip Design On Sun, 7 May 2000, Homer Wilson Smith wrote: > I was not able to get v92g to run in linux 2.0.36. > superoot jane/usr/local/main/tulip: insmod tulip.o > pci_drv_register: wrong version or undefined > pci_drv_unregister: wrong version or undefined > Loading failed! The module symbols (from linux-2.0.36) don't match your linux-2.0.36 You don't have 'pci-scan.o' loaded. If you used the RPM or Makefile install, you just need to do modprobe tulip instead of insmod tulip If you are installing by hand to test the module do /sbin/insmod pci-scan.o first. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From atterer@informatik.tu-muenchen.de Mon May 8 12:37:48 2000 Date: Mon May 8 12:37:48 2000 From: Richard Atterer atterer@informatik.tu-muenchen.de Subject: PCMCIA Driver for SMC 10/100 CardBus On Mon, May 08, 2000 at 02:01:15AM +0000, Donald Becker wrote: > On Sun, 7 May 2000, Richard Atterer wrote: > > > The SMC CardBus adapter is known to work. They sent me one to test with. > > > > When did they send it? I'm asking because they seem to have changed > > the design of the card without also changing the name or model > > number. (The PCMCIA ID *has* changed, though.) v0.91g most definitely > > doesn't work with it, and IIRC neither does 0.91x. > > Hmmm, probably a year or so ago. I can't find the paperwork on it. > > Load with debug=7 and send the output... I bought mine around Christmas. It needs the following entry in config.opts: card "SMC EZ CardBus 10/100 PC Card" manfid 0x01bf, 0x2220 bind "tulip" I have managed to build the v0.92 driver - however, I had to make cb_shim.o manually. The following was logged with debug=7 when I inserted the card. (It was already connected to the 10Mbit network here when I did so.) Note the "Failed to map PCI address 0x0 for device 'Digital DS21143 Tulip'". What's the problem? May 8 16:24:02 elessar cardmgr[278]: initializing socket 0 May 8 16:24:02 elessar cardmgr[278]: socket 0: SMC EZ CardBus 10/100 PC Card May 8 16:24:02 elessar kernel: cs: cb_alloc(bus 32): vendor 0x1011, device 0x0019 May 8 16:24:02 elessar kernel: ROM image dump: May 8 16:24:02 elessar kernel: image 0: 0x000000-0x0001ff, signature PCIR May 8 16:24:02 elessar cardmgr[278]: executing: 'insmod /lib/modules/2.2.13/pcmcia/cb_enabler.o' May 8 16:24:03 elessar cardmgr[278]: executing: 'insmod /lib/modules/2.2.13/net/pci-scan.o' May 8 16:24:03 elessar cardmgr[278]: executing: 'insmod /lib/modules/2.2.13/net/cb_shim.o' May 8 16:24:03 elessar kernel: cb_shim.c:v1.00 4/15/2000 Donald Becker May 8 16:24:03 elessar kernel: http://www.scyld.com/linux/drivers.html May 8 16:24:03 elessar cardmgr[278]: executing: 'insmod /lib/modules/2.2.13/net/tulip.o debug=7' May 8 16:24:03 elessar kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 8 16:24:03 elessar kernel: http://www.scyld.com/network/tulip.html May 8 16:24:03 elessar kernel: Failed to map PCI address 0x0 for device 'Digital DS21143 Tulip'. May 8 16:24:03 elessar kernel: cs: cb_config(bus 32) May 8 16:24:03 elessar kernel: fn 0 bar 1: io 0x400-0x47f May 8 16:24:03 elessar kernel: fn 0 bar 2: mem 0xa00c0000-0xa00c03ff May 8 16:24:03 elessar kernel: fn 0 rom: mem 0xa0080000-0xa00bffff May 8 16:24:03 elessar kernel: cs: cb_enable(bus 32) May 8 16:24:03 elessar kernel: bridge io map 0 (flags 0x21): 0x400-0x47f May 8 16:24:03 elessar kernel: bridge mem map 0 (flags 0x1): 0xa0080000-0xa00c0fff May 8 16:24:03 elessar kernel: Found a Digital DS21143 Tulip at 32/0 address 0xa00c0000->0xc4c58000 IRQ 10. May 8 16:24:03 elessar kernel: Digital DS21143 Tulip at 32/0 command 0x7. May 8 16:24:03 elessar kernel: eth0: Digital DS21143 Tulip rev 65 at 0xc4c58000, 00:E0:29:55:E1:12, IRQ 10. May 8 16:24:03 elessar kernel: eth0: EEPROM default media type Autosense. May 8 16:24:03 elessar kernel: eth0: MII interface PHY 0, setup/reset sequences 2/2 long, capabilities 02 08. May 8 16:24:03 elessar kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. May 8 16:24:03 elessar kernel: eth0: Using media type MII, CSR12 is c6. May 8 16:24:03 elessar kernel: eth0: MII transceiver #1 config 3000 status 7809 advertising 00a1. May 8 16:24:03 elessar kernel: eth0: Advertising 01e1 on PHY 1, previously advertising 00a1. May 8 16:24:03 elessar kernel: eth0: Handling power event 1. May 8 16:24:03 elessar cardmgr[278]: executing: './network start eth0' May 8 16:24:04 elessar kernel: eth0: tulip_open() irq 10. May 8 16:24:04 elessar kernel: eth0: Advertising 01e1 on MII 1. May 8 16:24:04 elessar kernel: eth0: Using media type MII, CSR12 is c6. May 8 16:24:04 elessar kernel: eth0: Using MII transceiver 1, status 7809. May 8 16:24:04 elessar kernel: eth0: MII link partner 0000, negotiated 0000. May 8 16:24:04 elessar kernel: eth0: No link beat on the MII interface, status 7809. May 8 16:24:04 elessar kernel: eth0: Done tulip_open(), CSR0 f8a08000, CSR5 f0120000 CSR6 b20e2002. May 8 16:24:04 elessar kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 8 16:24:04 elessar kernel: eth0: exiting interrupt, csr5=0xf0660000. May 8 16:24:04 elessar kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 8 16:24:04 elessar kernel: eth0: exiting interrupt, csr5=0xf0660000. May 8 16:24:04 elessar kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 8 16:24:04 elessar kernel: eth0: exiting interrupt, csr5=0xf0660000. May 8 16:24:07 elessar kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 8 16:24:07 elessar kernel: eth0: MII link partner 0000, negotiated 0000. May 8 16:24:07 elessar kernel: eth0: No link beat on the MII interface, status 7809. [ping machine on local net] May 8 16:26:00 elessar kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 8 16:26:00 elessar kernel: eth0: Transmit error, Tx status 7fffbc00. May 8 16:26:00 elessar kernel: eth0: exiting interrupt, csr5=0xf0660000. May 8 16:26:01 elessar kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 8 16:26:01 elessar kernel: eth0: Transmit error, Tx status 7fffbc00. May 8 16:26:01 elessar kernel: eth0: exiting interrupt, csr5=0xf0660000. May 8 16:26:02 elessar kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 8 16:26:02 elessar kernel: eth0: Transmit error, Tx status 7fffbc00. May 8 16:26:02 elessar kernel: eth0: exiting interrupt, csr5=0xf0660000. May 8 16:26:07 elessar kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 8 16:26:07 elessar kernel: eth0: MII link partner 0000, negotiated 0000. May 8 16:26:07 elessar kernel: eth0: No link beat on the MII interface, status 7809. May 8 16:27:07 elessar kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 8 16:27:07 elessar kernel: eth0: MII link partner 0000, negotiated 0000. May 8 16:27:07 elessar kernel: eth0: No link beat on the MII interface, status 7809. Cheers, Richard -- __ _ |_) /| Richard Atterer (currently at Queen's University, Belfast, NI) | \/�| http://www.in.tum.de/~atterer/ � �` � ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From cgarcia@exatec.itesm.mx Mon May 8 13:58:32 2000 Date: Mon May 8 13:58:32 2000 From: Carlos E. =?iso-8859-1?Q?Garc=EDa=20D=EDaz?= cgarcia@exatec.itesm.mx Subject: Laptop & SMC CardBus Hi, I have a Compaq Presario Laptop with an "SMC EZ CardBus 10/100 PC Card" and Linux Redhat 6.2. The NIC is recognized by cardmgr but it don't work. These are the file: The /var/log/messages May 5 20:25:11 mikonos pcmcia: Starting PCMCIA services: May 5 20:25:11 mikonos pcmcia: modules May 5 20:25:11 mikonos kernel: Linux PCMCIA Card Services 3.1.8 May 5 20:25:11 mikonos kernel: kernel build: 2.2.14-5.0 #1 Tue Mar 7 20:53:41 EST 2000 May 5 20:25:11 mikonos kernel: options: [pci] [cardbus] [apm] May 5 20:25:11 mikonos kernel: Intel PCIC probe: May 5 20:25:11 mikonos kernel: TI 1211 PCI-to-CardBus at bus 0 slot 10, mem 0x68000000, 1 socket May 5 20:25:11 mikonos kernel: host opts [0]: [ring] [pwr save] [pci + serial irq] [no pci irq] [lat 32/176] [bus 32/34] May 5 20:25:11 mikonos kernel: ISA irqs (scanned) = 3 polling interval = 1000 ms May 5 20:25:11 mikonos pcmcia: cardmgr. May 5 20:25:11 mikonos cardmgr[383]: starting, version is 3.1.8 May 5 20:25:11 mikonos rc: Starting pcmcia succeeded May 5 20:25:12 mikonos cardmgr[383]: watching 1 sockets May 5 20:25:12 mikonos kernel: cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x10ff 0x1400-0x14ff May 5 20:25:12 mikonos kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x388-0x38f 0x4d0-0x4d7 May 5 20:25:12 mikonos kernel: cs: IO port probe 0x0a00-0x0aff: clean. May 5 20:25:12 mikonos inet: inetd startup succeeded May 5 20:25:12 mikonos kernel: cs: cb_alloc(bus 32): vendor 0x1011, device 0x0019 May 5 20:25:12 mikonos cardmgr[383]: initializing socket 0 May 5 20:25:12 mikonos cardmgr[383]: socket 0: SMC EZ CardBus 10/100 PC Card May 5 20:25:12 mikonos cardmgr[383]: executing: 'insmod /lib/modules/2.2.14-5.0/pcmcia/cb_enabler.o' May 5 20:25:12 mikonos cardmgr[383]: executing: 'insmod /lib/modules/2.2.14-5.0/pcmcia/tulip_cb.o' May 5 20:25:12 mikonos kernel: cs: cb_config(bus 32) May 5 20:25:12 mikonos kernel: fn 0 bar 1: io 0x280-0x2ff May 5 20:25:12 mikonos kernel: fn 0 bar 2: mem 0x600c0000-0x600c03ff May 5 20:25:12 mikonos kernel: fn 0 rom: mem 0x60080000-0x600bffff May 5 20:25:12 mikonos kernel: tulip_attach(bus 32, function 0) May 5 20:25:12 mikonos kernel: tulip.c:v0.91 4/14/99 becker@cesdis.gsfc.nasa.gov (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) May 5 20:25:12 mikonos kernel: eth0: Digital DS21143 Tulip rev 65 at 0x280, FF:00:FF:00:03:00, IRQ 3. May 5 20:25:12 mikonos cardmgr[383]: executing: './network start eth0' . . . May 5 20:25:30 mikonos kernel: eth0: Tx hung, 10 vs. 7. May 5 20:25:30 mikonos kernel: eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbff7f 8ff00008, resetting... May 5 20:25:36 mikonos kernel: eth0: Tx hung, 10 vs. 7. May 5 20:25:36 mikonos kernel: eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbff7f 8ff00008, resetting... May 5 20:25:42 mikonos kernel: eth0: Tx hung, 11 vs. 7. May 5 20:25:42 mikonos kernel: eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbff7f 8ff00008, resetting... May 5 20:25:51 mikonos kernel: eth0: Tx hung, 9 vs. 7. May 5 20:25:51 mikonos kernel: eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbffff 8ff00008, resetting... May 5 20:25:57 mikonos kernel: eth0: Tx hung, 10 vs. 7. May 5 20:25:57 mikonos kernel: eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbffff 8ff00008, resetting... May 5 20:26:03 mikonos kernel: eth0: Tx hung, 10 vs. 7. May 5 20:26:03 mikonos kernel: eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbffff 8ff00008, resetting... May 5 20:26:09 mikonos kernel: eth0: Tx hung, 11 vs. 7. May 5 20:26:09 mikonos kernel: eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fffbffff 8ff00008, resetting... May 5 20:26:13 mikonos cardmgr[383]: + Determining IP information for eth0...Operation failed. May 5 20:26:13 mikonos cardmgr[383]: + failed. May 5 20:26:13 mikonos cardmgr[383]: start cmd exited with status 1 The /proc/pci : PCI devices found: Bus 32, device 0, function 0: Ethernet controller: DEC DC21142 (rev 65). Medium devsel. Fast back-to-back capable. IRQ 3. I/O at 0x280 [0x281]. Non-prefetchable 32 bit memory at 0x600c0000 [0x600c0000]. The /var/run/stab file: Socket 0: SMC EZ CardBus 10/100 PC Card 0 network tulip_cb 0 eth0 I added to the file /etc/pcmcia/config : card "SMC EZ CardBus 10/100 PC Card" manfid 0x01bf, 0x2220 bind "tulip_cb" and the card was correctly recognized by cardmgr. Thanks for your help. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From cbrown@denalics.net Mon May 8 15:07:31 2000 Date: Mon May 8 15:07:31 2000 From: Christopher E. Brown cbrown@denalics.net Subject: Adaptec ANA6944TX 21140 Issues I have a fairly fun issue with the tulip based Adaptec quad cards I am hoping to get some help on. I have multiple machines using a Tyan s1590s mainboard with 1 - 3 ANA6944 quad 21140 cards, some work perfectly, others refuse to operate. I have tried multiple mainboard revisions, bios revisions, all the cards are same rev/series. All configurations are the same (between working and non working test pairs), same PCI slots, same bios setting, same kernels. 2 exactly the same systems, one functions perfectly, the other does not, 89H, 91, and 92 tulip drivers *all* fail. Tested under 2.2.7ac4 - 2.2.15pre20, revisions 1.1 - 1.5 of the 1590, with BIOS 1.14, 1.16, and 1.16c. Normal case is, card is detected find, in proper order/etc, all MACS com up fine. Then, either all ports fail speed negs, *or* ports 2 and 4 work (most of the time), 1 and 3 fail. Somthing is up with he the MII autoneg stuff (it appears), but I am at a loss here, I can find no differences between working and failing systems. What info should I provide using what tools, kernel and driver versions? I have tulip-diag/mii-diag/mii_look/etc. Thanks Chris --- As folks might have suspected, not much survives except roaches, and they don't carry large enough packets fast enough... --About the Internet and nuclear war. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Mon May 8 15:08:10 2000 Date: Mon May 8 15:08:10 2000 From: Donald Becker becker@scyld.com Subject: PCMCIA Driver for SMC 10/100 CardBus On Mon, 8 May 2000, Richard Atterer wrote: > > > When did they send it? I'm asking because they seem to have changed > > > the design of the card without also changing the name or model > > > number. (The PCMCIA ID *has* changed, though.) v0.91g most definitely > > > doesn't work with it, and IIRC neither does 0.91x. > > > > Hmmm, probably a year or so ago. I can't find the paperwork on it. > > > > Load with debug=7 and send the output... > > I bought mine around Christmas. It needs the following entry in config.opts: > > card "SMC EZ CardBus 10/100 PC Card" > manfid 0x01bf, 0x2220 > bind "tulip" OK, that is different. The line I have on the update page http://www.scyld.com/network/index.html is card "SMC EZ CardBus 10/100 Ethernet" manfid 0x01bf, 0x2225 bind "tulip" I'll have to add card "SMC EZ CardBus 10/100 Ethernet" manfid 0x01bf, 0x2220 bind "tulip" > I have managed to build the v0.92 driver - however, I had to make > cb_shim.o manually. The following was logged with debug=7 when I > inserted the card. (It was already connected to the 10Mbit network > here when I did so.) How did you build the driver? The Makefile should build cb_shim automatically, but only if it finds the PCMCIA include files. I guess I need to add a search path... > Note the "Failed to map PCI address 0x0 for device 'Digital DS21143 > Tulip'". What's the problem? > May 8 16:24:03 elessar kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker > May 8 16:24:03 elessar kernel: http://www.scyld.com/network/tulip.html > May 8 16:24:03 elessar kernel: Failed to map PCI address 0x0 for device 'Digital DS21143 Tulip'. Hmmm, I don't know what is triggering this message. It looks as if the card exists in the PCI table at this point (is the CardBus code adding it?), but hasn't been assigned resources. > May 8 16:24:03 elessar kernel: Found a Digital DS21143 Tulip at 32/0 address 0xa00c0000->0xc4c58000 IRQ 10. > May 8 16:24:03 elessar kernel: Digital DS21143 Tulip at 32/0 command 0x7. > May 8 16:24:03 elessar kernel: eth0: Digital DS21143 Tulip rev 65 at 0xc4c58000, 00:E0:29:55:E1:12, IRQ 10. > May 8 16:24:03 elessar kernel: eth0: EEPROM default media type Autosense. > May 8 16:24:03 elessar kernel: eth0: MII interface PHY 0, setup/reset sequences 2/2 long, capabilities 02 08. > May 8 16:24:03 elessar kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. This is a MII card. The only non-obvious attribute is that it has a transceiver reset method. > May 8 16:24:03 elessar kernel: eth0: MII transceiver #1 config 3000 status 7809 advertising 00a1. > May 8 16:24:03 elessar kernel: eth0: Advertising 01e1 on PHY 1, previously advertising 00a1. Hmmm, it powered up advertising only half duplex media types!? > May 8 16:24:04 elessar kernel: eth0: No link beat on the MII interface, status 7809. You don't have link beat. Are you certain the cable is good, and the dongle is connected? (A common problem is a broken dongle.) > May 8 16:26:00 elessar kernel: eth0: Transmit error, Tx status 7fffbc00. No link beat. It's faintly possible that this is caused by an incorrectly reset transceiver. But it really looks like you have a standard case of no network connectino. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Mon May 8 15:10:59 2000 Date: Mon May 8 15:10:59 2000 From: Donald Becker becker@scyld.com Subject: Laptop & SMC CardBus On Mon, 8 May 2000, Carlos E. [iso-8859-1] Garc�a D�az wrote: > I have a Compaq Presario Laptop with an "SMC EZ CardBus 10/100 PC Card" > and Linux Redhat 6.2. The NIC is recognized by cardmgr but it don't > work. .. > May 5 20:25:12 mikonos kernel: tulip.c:v0.91 4/14/99 > becker@cesdis.gsfc.nasa.gov (modified by danilo@cs.uni-magdeburg.de for > XIRCOM CBE, fixed by Doug Ledford) That's an old, modified driver version. "Not my fault." > May 5 20:25:12 mikonos kernel: eth0: Digital DS21143 Tulip rev 65 at > 0x280, FF:00:FF:00:03:00, IRQ 3. The driver read the EEPROM incorrectly. Run 'tulip-diag' to verify the EEPROM has reasonable contents -- it likely does, it's just that driver doesn't read the EEPROM correctly. http://www.scyld.com/diag/index.html Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From atterer@informatik.tu-muenchen.de Mon May 8 15:30:51 2000 Date: Mon May 8 15:30:51 2000 From: Richard Atterer atterer@informatik.tu-muenchen.de Subject: PCMCIA Driver for SMC 10/100 CardBus On Mon, May 08, 2000 at 09:08:07PM +0000, Donald Becker wrote: > On Mon, 8 May 2000, Richard Atterer wrote: [snip] > > I have managed to build the v0.92 driver - however, I had to make > > cb_shim.o manually. The following was logged with debug=7 when I > > inserted the card. (It was already connected to the 10Mbit network > > here when I did so.) > > How did you build the driver? The Makefile should build cb_shim > automatically, but only if it finds the PCMCIA include files. > I guess I need to add a search path... Um, no - the pcmcia source is in my home directory, that's where I built it... Maybe you should check for /lib/modules/*/pcmcia or /sbin/cardmgr and give an error message if that is present, but the include files can't be found. [snip] > > May 8 16:24:04 elessar kernel: eth0: No link beat on the MII interface, status 7809. > > You don't have link beat. Are you certain the cable is good, and the dongle > is connected? (A common problem is a broken dongle.) It all works fine under "The Other OS". :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer (currently at Queen's University, Belfast, NI) | \/�| http://www.in.tum.de/~atterer/ � �` � ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Mon May 8 16:39:04 2000 Date: Mon May 8 16:39:04 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus After installing the new network driver RPM, my /var/log/messages complains it can't find pci-netif. I did an updatedb and a locate and still couldn't find it. I wonder where it went. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Mon May 8 16:39:48 2000 Date: Mon May 8 16:39:48 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus This is a multi-part message in MIME format. --------------AAAF4C85623086A15458BF2D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I forgot to attach the relevant lines from /var/log/messages... --------------AAAF4C85623086A15458BF2D Content-Type: text/plain; charset=us-ascii; name="messages.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages.txt" May 8 16:15:19 rocky kudzu: succeeded May 8 16:15:19 rocky sysctl: net.ipv4.ip_forward = 0 May 8 16:15:19 rocky sysctl: net.ipv4.conf.all.rp_filter = 1 May 8 16:15:19 rocky sysctl: net.ipv4.ip_always_defrag = 0 May 8 16:15:19 rocky sysctl: error: 'kernel.sysrq' is an unknown key May 8 16:15:19 rocky network: Setting network parameters succeeded May 8 16:15:19 rocky network: Bringing up interface lo succeeded May 8 16:15:19 rocky modprobe: modprobe: Can't locate module tr0 May 8 16:15:19 rocky portmap: portmap startup succeeded May 8 16:15:20 rocky nfslock: rpc.lockd startup succeeded May 8 16:15:20 rocky nfslock: rpc.statd startup succeeded May 8 16:15:20 rocky apmd[314]: Version 3.0final (APM BIOS 1.2, Linux driver 1.9) May 8 16:15:20 rocky apmd: apmd startup succeeded May 8 16:15:20 rocky random: Initializing random number generator succeeded May 8 16:15:20 rocky netfs: Mounting other filesystems succeeded May 8 16:15:22 rocky crond: crond startup succeeded May 8 16:15:24 rocky pcmcia: Starting PCMCIA services: May 8 16:15:24 rocky pcmcia: modules May 8 16:15:24 rocky kernel: Linux PCMCIA Card Services 3.1.8 May 8 16:15:24 rocky kernel: kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 May 8 16:15:24 rocky kernel: options: [pci] [cardbus] [apm] May 8 16:15:24 rocky kernel: Intel PCIC probe: May 8 16:15:24 rocky kernel: TI 1225 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets May 8 16:15:24 rocky kernel: host opts [0]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 32/34] May 8 16:15:24 rocky kernel: host opts [1]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 35/37] May 8 16:15:24 rocky kernel: ISA irqs (scanned) = 3,4,7,9,10 polling interval = 1000 ms May 8 16:15:24 rocky pcmcia: cardmgr. May 8 16:15:24 rocky cardmgr[435]: starting, version is 3.1.8 May 8 16:15:24 rocky rc: Starting pcmcia succeeded May 8 16:15:25 rocky cardmgr[435]: config error, file './config.opts' line 44: unknown device: tulip_cb May 8 16:15:25 rocky cardmgr[435]: config error, file './config.opts' line 63: unknown device: rtl8139 May 8 16:15:25 rocky cardmgr[435]: config error, file './config.opts' line 66: unknown device: rtl8139 May 8 16:15:25 rocky lpd: lpd startup succeeded May 8 16:15:25 rocky lpd[449]: restarted May 8 16:15:25 rocky cardmgr[435]: watching 2 sockets May 8 16:15:25 rocky kernel: cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x1087 May 8 16:15:25 rocky kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 May 8 16:15:25 rocky kernel: cs: IO port probe 0x0a00-0x0aff: clean. May 8 16:15:25 rocky kernel: cs: cb_alloc(bus 35): vendor 0x1011, device 0x0019 May 8 16:15:25 rocky kernel: kmem_grow: Called nonatomically from int - size-128 May 8 16:15:25 rocky cardmgr[435]: initializing socket 1 May 8 16:15:25 rocky cardmgr[435]: unsupported card in socket 1 May 8 16:15:25 rocky keytable: Loading keymap: May 8 16:15:25 rocky cardmgr[435]: product info: "SMC", "EZ CardBus 10/100 PC Card" May 8 16:15:25 rocky cardmgr[435]: manfid: 0x01bf, 0x2220 function: 6 (network) May 8 16:15:25 rocky keytable: Loading /usr/lib/kbd/keymaps/i386/qwerty/us.kmap.gz May 8 16:15:26 rocky keytable: Loading system font: May 8 16:15:26 rocky rc: Starting keytable succeeded May 8 16:15:27 rocky sendmail: sendmail startup succeeded May 8 16:15:27 rocky gpm: gpm startup succeeded May 8 16:15:29 rocky xfs: Warning: The directory "/usr/share/fonts/default/TrueType" does not exist. May 8 16:15:29 rocky xfs: Entry deleted from font path. May 8 16:15:29 rocky xfs: xfs startup succeeded May 8 16:15:29 rocky linuxconf: Linuxconf final setup May 8 16:15:30 rocky rc: Starting linuxconf succeeded May 8 16:15:31 rocky kernel: Lucent Modem driver version 4.27.5.66 with MANY_PORTS MULTIPORT SHARE_IRQ enabled May 8 16:15:31 rocky kernel: ttyS14 at 0x1800 (irq = 5) is a Lucent May 8 16:15:35 rocky PAM_pwdb[585]: (login) session opened for user root by LOGIN(uid=0) May 8 16:18:19 rocky cardmgr[435]: exiting May 8 16:18:21 rocky kernel: cs: cb_free(bus 35) May 8 16:18:21 rocky kernel: unloading PCMCIA Card Services May 8 16:18:26 rocky kernel: Linux PCMCIA Card Services 3.1.8 May 8 16:18:26 rocky kernel: kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 May 8 16:18:26 rocky kernel: options: [pci] [cardbus] [apm] May 8 16:18:26 rocky kernel: Intel PCIC probe: May 8 16:18:26 rocky kernel: TI 1225 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets May 8 16:18:26 rocky kernel: host opts [0]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 32/34] May 8 16:18:26 rocky kernel: host opts [1]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 35/37] May 8 16:18:26 rocky kernel: ISA irqs (scanned) = 3,4,7,9,10 polling interval = 1000 ms May 8 16:18:26 rocky cardmgr[638]: starting, version is 3.1.8 May 8 16:18:26 rocky cardmgr[638]: config error, file './config.opts' line 44: unknown device: tulip_cb May 8 16:18:26 rocky cardmgr[638]: config error, file './config.opts' line 63: unknown device: rtl8139 May 8 16:18:26 rocky cardmgr[638]: config error, file './config.opts' line 66: unknown device: rtl8139 May 8 16:18:26 rocky cardmgr[638]: watching 2 sockets May 8 16:18:26 rocky kernel: cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x1087 May 8 16:18:26 rocky kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 May 8 16:18:26 rocky kernel: cs: IO port probe 0x0a00-0x0aff: clean. May 8 16:18:27 rocky kernel: cs: cb_alloc(bus 35): vendor 0x1011, device 0x0019 May 8 16:18:27 rocky cardmgr[638]: initializing socket 1 May 8 16:18:27 rocky cardmgr[638]: unsupported card in socket 1 May 8 16:18:27 rocky cardmgr[638]: product info: "SMC", "EZ CardBus 10/100 PC Card" May 8 16:18:27 rocky cardmgr[638]: manfid: 0x01bf, 0x2220 function: 6 (network) May 8 16:19:57 rocky cardmgr[638]: exiting May 8 16:19:59 rocky kernel: cs: cb_free(bus 35) May 8 16:19:59 rocky kernel: unloading PCMCIA Card Services May 8 16:20:02 rocky kernel: Linux PCMCIA Card Services 3.1.8 May 8 16:20:02 rocky kernel: kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 May 8 16:20:02 rocky kernel: options: [pci] [cardbus] [apm] May 8 16:20:02 rocky kernel: Intel PCIC probe: May 8 16:20:02 rocky kernel: TI 1225 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets May 8 16:20:02 rocky kernel: host opts [0]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 32/34] May 8 16:20:02 rocky kernel: host opts [1]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 35/37] May 8 16:20:02 rocky kernel: ISA irqs (scanned) = 3,4,7,9,10 polling interval = 1000 ms May 8 16:20:02 rocky cardmgr[661]: starting, version is 3.1.8 May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 40: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 41: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 42: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 43: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 45: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 46: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 47: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 50: unknown device: tulip May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 63: unknown device: rtl8139 May 8 16:20:02 rocky cardmgr[661]: config error, file './config.opts' line 66: unknown device: rtl8139 May 8 16:20:02 rocky cardmgr[661]: watching 2 sockets May 8 16:20:02 rocky kernel: cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x1087 May 8 16:20:02 rocky kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 May 8 16:20:02 rocky kernel: cs: IO port probe 0x0a00-0x0aff: clean. May 8 16:20:03 rocky kernel: cs: cb_alloc(bus 35): vendor 0x1011, device 0x0019 May 8 16:20:03 rocky cardmgr[661]: initializing socket 1 May 8 16:20:03 rocky cardmgr[661]: socket 1: SMC EZ CardBus 10/100 PC CARD May 8 16:20:03 rocky cardmgr[661]: executing: 'insmod /lib/modules/2.2.14-5.0/pcmcia/cb_enabler.o' May 8 16:20:03 rocky cardmgr[661]: module /lib/modules/2.2.14-5.0/pcmcia/pci-netif.o not available May 8 16:20:03 rocky cardmgr[661]: module /lib/modules/2.2.14-5.0/pcmcia/cb_shim.o not available May 8 16:20:03 rocky cardmgr[661]: module /lib/modules/2.2.14-5.0/pcmcia/tulip.o not available May 8 16:20:04 rocky cardmgr[661]: get dev info on socket 1 failed: Resource temporarily unavailable May 8 16:21:27 rocky gnome-name-server[713]: starting May 8 16:21:27 rocky gnome-name-server[713]: name server starting May 8 16:22:59 rocky modprobe: modprobe: Can't locate module tr0 May 8 16:23:04 rocky ifup-ppp: pppd started for ppp0 on /dev/ttyS14 at 57600 May 8 16:23:05 rocky kernel: registered device ppp0 May 8 16:23:05 rocky pppd[951]: pppd 2.3.11 started by root, uid 0 May 8 16:23:06 rocky WvDial: WvDial: Internet dialer version 1.41 May 8 16:23:06 rocky WvDial: Initializing modem. May 8 16:23:06 rocky WvDial: Sending: ATZ May 8 16:23:06 rocky WvDial: ATZ May 8 16:23:06 rocky WvDial: OK May 8 16:23:06 rocky WvDial: Modem initialized. May 8 16:23:06 rocky WvDial: Sending: ATDT 1,8106939491 May 8 16:23:06 rocky WvDial: Waiting for carrier. May 8 16:23:06 rocky WvDial: ATDT 1,8106939491 May 8 16:23:27 rocky cardmgr[661]: shutting down socket 1 May 8 16:23:27 rocky cardmgr[661]: executing: 'rmmod tulip' May 8 16:23:27 rocky cardmgr[661]: + rmmod: module tulip is not loaded May 8 16:23:27 rocky cardmgr[661]: rmmod exited with status 1 May 8 16:23:27 rocky cardmgr[661]: executing: 'rmmod cb_shim' May 8 16:23:27 rocky cardmgr[661]: + rmmod: module cb_shim is not loaded May 8 16:23:27 rocky cardmgr[661]: rmmod exited with status 1 May 8 16:23:27 rocky cardmgr[661]: executing: 'rmmod pci-netif' May 8 16:23:27 rocky cardmgr[661]: + rmmod: module pci-netif is not loaded May 8 16:23:27 rocky cardmgr[661]: rmmod exited with status 1 May 8 16:23:27 rocky cardmgr[661]: executing: 'rmmod cb_enabler' May 8 16:23:27 rocky cardmgr[661]: exiting May 8 16:23:29 rocky kernel: cs: cb_free(bus 35) May 8 16:23:29 rocky kernel: unloading PCMCIA Card Services May 8 16:23:39 rocky PAM_pwdb[992]: (su) session opened for user tgagne by root(uid=0) May 8 16:23:46 rocky WvDial: CONNECT 24000 V42bis May 8 16:23:46 rocky WvDial: Carrier detected. Waiting for prompt. May 8 16:23:47 rocky WvDial: Welcome to MindSpring Dialup Service May 8 16:23:47 rocky WvDial: arc-1a.det login: May 8 16:23:47 rocky WvDial: Looks like a login prompt. May 8 16:23:47 rocky WvDial: Sending: #tgagne May 8 16:23:48 rocky WvDial: #tgagne May 8 16:23:48 rocky WvDial: Password: May 8 16:23:48 rocky WvDial: Looks like a password prompt. May 8 16:23:48 rocky WvDial: Sending: (password) May 8 16:23:48 rocky WvDial: Packet mode enabled: ~[7f]}#@!}!}!} }8}!}$}%\}"}&[7f][7f][7f][7f]}%}&[19]4[19];}'}"}(}"N4~ May 8 16:23:48 rocky WvDial: PPP negotiation detected. May 8 16:23:48 rocky pppd[951]: Serial connection established. May 8 16:23:48 rocky pppd[951]: Using interface ppp0 May 8 16:23:48 rocky pppd[951]: Connect: ppp0 <--> /dev/ttyS14 May 8 16:23:51 rocky kernel: PPP BSD Compression module registered May 8 16:23:51 rocky kernel: PPP Deflate Compression module registered May 8 16:23:51 rocky pppd[951]: local IP address 165.121.208.121 May 8 16:23:51 rocky pppd[951]: remote IP address 168.121.1.1 May 8 16:23:51 rocky pppd[951]: primary DNS address 207.69.188.186 May 8 16:23:51 rocky pppd[951]: secondary DNS address 207.69.188.185 May 8 16:23:51 rocky modprobe: modprobe: Can't locate module tr0 May 8 16:23:58 rocky PAM_pwdb[992]: (su) session closed for user tgagne May 8 16:24:03 rocky PAM_pwdb[1075]: (su) session opened for user tgagne by root(uid=0) May 8 16:29:21 rocky kernel: Linux PCMCIA Card Services 3.1.8 May 8 16:29:21 rocky kernel: kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 May 8 16:29:21 rocky kernel: options: [pci] [cardbus] [apm] May 8 16:29:21 rocky kernel: Intel PCIC probe: May 8 16:29:21 rocky kernel: TI 1225 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets May 8 16:29:21 rocky kernel: host opts [0]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 32/34] May 8 16:29:21 rocky kernel: host opts [1]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 35/37] May 8 16:29:21 rocky kernel: ISA irqs (scanned) = 3,4,7,9,10 polling interval = 1000 ms May 8 16:29:21 rocky cardmgr[1430]: starting, version is 3.1.8 May 8 16:29:21 rocky cardmgr[1430]: config error, file './config.opts' line 63: unknown device: rtl8139 May 8 16:29:21 rocky cardmgr[1430]: config error, file './config.opts' line 66: unknown device: rtl8139 May 8 16:29:21 rocky cardmgr[1430]: watching 2 sockets May 8 16:29:21 rocky kernel: cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x1087 May 8 16:29:21 rocky kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 May 8 16:29:21 rocky kernel: cs: IO port probe 0x0a00-0x0aff: clean. May 8 16:29:22 rocky kernel: cs: cb_alloc(bus 35): vendor 0x1011, device 0x0019 May 8 16:29:22 rocky cardmgr[1430]: initializing socket 1 May 8 16:29:22 rocky cardmgr[1430]: socket 1: SMC EZ CardBus 10/100 PC CARD May 8 16:29:22 rocky cardmgr[1430]: executing: 'insmod /lib/modules/2.2.14-5.0/pcmcia/cb_enabler.o' May 8 16:29:22 rocky cardmgr[1430]: module /lib/modules/2.2.14-5.0/pcmcia/pci-netif.o not available May 8 16:29:22 rocky cardmgr[1430]: module /lib/modules/2.2.14-5.0/pcmcia/cb_shim.o not available May 8 16:29:22 rocky cardmgr[1430]: module /lib/modules/2.2.14-5.0/pcmcia/tulip.o not available May 8 16:29:23 rocky cardmgr[1430]: get dev info on socket 1 failed: Resource temporarily unavailable May 8 16:29:55 rocky kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 8 16:29:55 rocky kernel: http://www.scyld.com/network/tulip.html May 8 16:29:55 rocky kernel: The PCI BIOS has not enabled the device at 35/0! Updating PCI command 0002->0006. May 8 16:29:55 rocky kernel: eth0: Digital DS21143 Tulip rev 65 at 0xd008f000, EEPROM not present, 00:4C:69:6E:75:79, IRQ 0. May 8 16:29:55 rocky kernel: eth0: Old style EEPROM with no media selection information. May 8 16:29:55 rocky kernel: PCI: Increasing latency timer of device 23:00 to 64 May 8 16:37:08 rocky PAM_pwdb[1463]: (su) session opened for user root by root(uid=500) --------------AAAF4C85623086A15458BF2D-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From homer@lightlink.com Mon May 8 19:28:27 2000 Date: Mon May 8 19:28:27 2000 From: Homer Wilson Smith homer@lightlink.com Subject: Digital Tulip Design > On Sun, 7 May 2000, Homer Wilson Smith wrote: > > > I was not able to get v92g to run in linux 2.0.36. > > superoot jane/usr/local/main/tulip: insmod tulip.o > > pci_drv_register: wrong version or undefined > > pci_drv_unregister: wrong version or undefined > > Loading failed! The module symbols (from linux-2.0.36) don't match your linux-2.0.36 > > You don't have 'pci-scan.o' loaded. Thank you Donald, sorry I am such a space cadet. This worked beautifully, still no FD on 21143 Kingstons. Using insmod tulip options=x AFTER pci_scan is loaded, the only options that tulip diag reports as full duplex are 4,5,8,10,26 and 27. All of these produce a jammed line, pings do not work for example, and no FD light on, on the Kingston. Perhaps I am doing something stupid, you know new user syndrome? Perhaps it is a problem with Cisco 1900 Switches in Full Dup mode? Running Linux 2.0.36, output of td below, option=0. If you wish other options, or other diagnostics run, be happy to do so. Homer Script started on Mon May 10 19:23:24 1999 superoot jane/root: May 10 19:25:46 jane kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 10 19:25:46 jane kernel: http://www.scyld.com/network/tulip.html May 10 19:25:46 jane kernel: eth0: Digital DS21143 Tulip rev 65 at 0x2820000, 00:40:F0:4C:E6:A9, IRQ 11. May 10 19:25:46 jane kernel: eth0: EEPROM default media type Autosense. May 10 19:25:46 jane kernel: eth0: Index #0 - Media MII 100baseTx (#13) described by a 21140 non-MII (0) block. May 10 19:25:46 jane kernel: eth0: MII transceiver #1 config 3100 status 782d advertising 03e0. Module: #pages: Used by: tulip 7 1 pci-scan 1 [tulip] 0 (autoclean) superoot jane/root: td tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0xe800. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. 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. superoot jane/root: td -ee tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0xe800. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM size is 6. PCI Subsystem IDs, vendor 2646, device 0001. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:C0:F0:4C:E6:A9. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 13. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 0 words:. 21143 MII reset sequence is 0 words:. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. EEPROM contents: 2646 0001 0000 0000 0000 0000 0000 0300 10a6 0104 c000 4cf0 a9e6 1e00 0000 0800 8d01 0003 0000 7800 01e0 5000 1800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 374b 9d6c 0000 0000 0000 c000 4cf0 a9e6 0040 0000 0000 0000 0000 0000 0000 0000 0000 0037 ID block CRC 0xa6 (vs. 0xa6). Full contents CRC 0xad86 (read as 0x0037). MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 3100 782d 0016 f840 03e0 0021 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff 0022 ff00 0000 ffc0 00a0 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. Internal autonegotiation state is 'Autonegotiation disabled'. superoot jane/root: ^Dexit Script done on Mon May 10 19:23:33 1999 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Mon May 8 21:05:35 2000 Date: Mon May 8 21:05:35 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: PCMCIA Driver for SMC 10/100 CardBus This is a multi-part message in MIME format. --------------DC4C118F21A498463713F046 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, I included too much. I've attached a smaller clip of the file. The problems I'm seeing: My system doesn't have a pci-netif.o file. I've looked everywhere, and it doesn't appear to be included in Donals's FTP directory. Of course, I'm unsure it's supposed to be there. The cb_enabler.o and tulip.o files aren't found, because the loader is looking for them in the pcmcia subdirectory, when both are installed by the RPM into the /net subdirectory. Is it safe to move them? Does it do me any good to move them if I'm still without pci-netif.o? --------------DC4C118F21A498463713F046 Content-Type: text/plain; charset=us-ascii; name="messages.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages.txt" May 8 16:29:21 rocky kernel: Linux PCMCIA Card Services 3.1.8 May 8 16:29:21 rocky kernel: kernel build: 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 May 8 16:29:21 rocky kernel: options: [pci] [cardbus] [apm] May 8 16:29:21 rocky kernel: Intel PCIC probe: May 8 16:29:21 rocky kernel: TI 1225 PCI-to-CardBus at bus 0 slot 4, mem 0x68000000, 2 sockets May 8 16:29:21 rocky kernel: host opts [0]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 32/34] May 8 16:29:21 rocky kernel: host opts [1]: [ring] [pwr save] [serial pci & irq] [no pci irq] [lat 168/32] [bus 35/37] May 8 16:29:21 rocky kernel: ISA irqs (scanned) = 3,4,7,9,10 polling interval = 1000 ms May 8 16:29:21 rocky cardmgr[1430]: starting, version is 3.1.8 May 8 16:29:21 rocky cardmgr[1430]: config error, file './config.opts' line 63: unknown device: rtl8139 May 8 16:29:21 rocky cardmgr[1430]: config error, file './config.opts' line 66: unknown device: rtl8139 May 8 16:29:21 rocky cardmgr[1430]: watching 2 sockets May 8 16:29:21 rocky kernel: cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x1087 May 8 16:29:21 rocky kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 May 8 16:29:21 rocky kernel: cs: IO port probe 0x0a00-0x0aff: clean. May 8 16:29:22 rocky kernel: cs: cb_alloc(bus 35): vendor 0x1011, device 0x0019 May 8 16:29:22 rocky cardmgr[1430]: initializing socket 1 May 8 16:29:22 rocky cardmgr[1430]: socket 1: SMC EZ CardBus 10/100 PC CARD May 8 16:29:22 rocky cardmgr[1430]: executing: 'insmod /lib/modules/2.2.14-5.0/pcmcia/cb_enabler.o' May 8 16:29:22 rocky cardmgr[1430]: module /lib/modules/2.2.14-5.0/pcmcia/pci-netif.o not available May 8 16:29:22 rocky cardmgr[1430]: module /lib/modules/2.2.14-5.0/pcmcia/cb_shim.o not available May 8 16:29:22 rocky cardmgr[1430]: module /lib/modules/2.2.14-5.0/pcmcia/tulip.o not available May 8 16:29:23 rocky cardmgr[1430]: get dev info on socket 1 failed: Resource temporarily unavailable May 8 16:29:55 rocky kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 8 16:29:55 rocky kernel: http://www.scyld.com/network/tulip.html May 8 16:29:55 rocky kernel: The PCI BIOS has not enabled the device at 35/0! Updating PCI command 0002->0006. May 8 16:29:55 rocky kernel: eth0: Digital DS21143 Tulip rev 65 at 0xd008f000, EEPROM not present, 00:4C:69:6E:75:79, IRQ 0. May 8 16:29:55 rocky kernel: eth0: Old style EEPROM with no media selection information. May 8 16:29:55 rocky kernel: PCI: Increasing latency timer of device 23:00 to 64 May 8 16:37:08 rocky PAM_pwdb[1463]: (su) session opened for user root by root(uid=500) --------------DC4C118F21A498463713F046-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Mon May 8 21:45:56 2000 Date: Mon May 8 21:45:56 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: SMC card working? I won't know for sure until I get to work, but after loading pcmcia-cs-3.1.14.tar.gz and making one change to config.opts, I got two high beeps when pcmcia loaded. Let's hope for the best... ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Tue May 9 07:24:35 2000 Date: Tue May 9 07:24:35 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: SMC card working? It certainly appears so! After loading the new tarfile I only had to edit: /etc/pcmcia/config.opts - use device tulip_cb instead of tulip for the SMC card. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From john@casc.com Tue May 9 11:05:40 2000 Date: Tue May 9 11:05:40 2000 From: John Stoffel john@casc.com Subject: Problems with the Netgear FA310TX - Broadcasts and TX Lockup >> tulip-0.90q >> tulip-0.90z >> tulip-0.91g (from 2.2.15pre??) >> tulip-0.91g-ppc (from 2.2.15pre13) Donald> These versions should work the PNIC-I, although I tested the Donald> original code not the modified versions in the kernel. ("With Donald> many eyes, all bugs are shallow. With many fingers, all bugs Donald> exist.") I tried the .92 version of the driver last night and I got the same problems. Lots of dropped packets and horrible performance. I had three systems up and running at this time: SparcClassic, Linux 2.2.15pre13, Sun HME 10/100 card, connected at 100mb/s Mac Performa 6100CD with MacOS 7.5.5, 10mb/s connection Problem box, Linux 2.2.15pre13, NetGear Card, .92 driver. The Space and the Mac were very happy talking back and forth with each other, with each on one side of the NetGear DS108 DualSpeed hub I have at home. I had been starting to think it was a hub problem, but since they worked fine, I still think it's a card/driver issue. >> Basically, when I ifconfig eth0 up, it auto-negotiates to be >> 100baseTx, which is great, this is exactly what the [pc] does as Donald> ... >> But I can't seem to send packets to either the classic or the pc >> without lots of timeouts and dropped packets. The performance is Donald> What is the timeout message? I'm especially interested in the Donald> v92 driver message. I got and compiled the .92 driver last night, but I had to fight a bit to make it and pci-scan.c compile properly without tons of warnings. Ended up commenting out the include for k_compat.h and/or kern_compat.h to get it to compile. I also modified the source to set debug=7 but default, but since I compiled as a module, I maybe need to actually use the options with insmod? Anyway, the message I got in the logs (which is from memory since I didn't have time to make notes last night after fighting the compile) from the .92 driver was: Advertised 401a, negotiated 001a which I assume means it wanted 100baseTx-FD, but got 100baseTx-HD instead, which is fine. But the wierd thing is that I kept getting these messages fairly frequently in the logs. It's as if it was trying to re-negotiate all the time. Tonight I'll try to get more detailed info with tulip-diag and mii-diag, along with log messages. >> eth0: Lite-On 82c168 PNIC rev 32 at 0x6100, 00:A0:CC:57:9A:C1, IRQ 10. >> eth0: MII transceiver #1 config 3000 status 782d advertising 01e1. Donald> Looks normal. I traced this down to a 82c169 board produced Donald> around mid-'98. The same board layout was sold under Donald> Kingston, Linksys and Netgear brands. Donald> I tried out the Linksys version (thanks to Linksys for Donald> providing a sample!), and it works fine with tulip.c v092 in a Donald> BP6 (dual Celeron 440BX) talking to a Linksys 5 port 10/100 Donald> switch (purchased, not a sample :-<). Donald> ..And it works through a Intel InBusiness 10+100 repeater, Donald> which should be the same type of hardware you have. I guess I'll try to get another switch and/or hub and see what my tests show with this card and driver. Donald, a big thanks for all your help here! I really appreciate the work you've put into this for me. John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548 john.stoffel@ascend.com - http://www.ascend.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tgagne@ix.netcom.com Tue May 9 17:35:52 2000 Date: Tue May 9 17:35:52 2000 From: Thomas Gagne tgagne@ix.netcom.com Subject: SMC card working? I noticed only one strange phenomona today: when computers send my laptop a lot of data quickly, the Xserver seems to get confused and the program *appears* to hang. I was watching the network via tcpdump and it looks like the systems are still running, they just stop displaying. Affected programs include telnet, rlogin, and X. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From rgb@phy.duke.edu Tue May 9 20:07:37 2000 Date: Tue May 9 20:07:37 2000 From: Robert G. Brown rgb@phy.duke.edu Subject: SMC card working? On Tue, 9 May 2000, Thomas Gagne wrote: > I noticed only one strange phenomona today: when computers send my laptop a > lot of data quickly, the Xserver seems to get confused and the program > *appears* to hang. I was watching the network via tcpdump and it looks like > the systems are still running, they just stop displaying. Affected programs > include telnet, rlogin, and X. Hmmm. This sounds like it could be a problem in the TCP stack that Josip Loncaric on the kernel list has been working on for some time. It appears that under certain heavy TCP usage patterns a hideous latency is introduced (I want to say on the order of ms but I truly cannot remember). While the driver is "hung" waiting to get back to the stream packets build up and the system can get very unhappy or even crash. He wrote a tuning patch for the kernel. Being the sort who squirrels this sort of thing away against the day it bites, I even have the URL handy: Explanation/use: http://www.icase.edu/coral/LinuxTCP2.html Patch for RH6.2: http://www.icase.edu/~josip/tcp-patch-for-2.2.14-5.0 I'm certainly not certain that this is your problem -- there are also some memory map problems and other sorts of things that could produce this sort of result on rare systems (I have one, so I know:-) or just plain not having enough memory can of course do it -- a high speed data stream can eat memory buffering it. If your laptop has only 64 MB and is running X, you might watch "free" (or procstat, or xosview or MGM or even top) to see what happens to your memory when this happens. You might just be running out and swapping. At this moment I'm doing a make -j3 kernel build on a dual with 128 MB and X "hangs" just like you describe when I change views because the parallel make sucks up memory like crazy. HTH, rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From cyberpir8@cyberpir8.yi.org Tue May 9 22:37:46 2000 Date: Tue May 9 22:37:46 2000 From: Chris Leavoy cyberpir8@cyberpir8.yi.org Subject: Prolems with tulip driver I have recently purchased a Network Anywhere NC100 v2, Linksys Fast Ethernet 10/100 from future shit. I am having a whole bunch of problems with this card, and trying to get it working properly in linux with the tulip module driver. ---- syslogd snip ---- kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. kernel: eth0: exiting interrupt, csr5=0xfc264010. kernel: eth0: interrupt csr5=0xfc674015 new csr5=0xfc664010. kernel: eth0: exiting interrupt, csr5=0xfc664010. kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. kernel: eth0: exiting interrupt, csr5=0xfc264010. ---- end snip ---- I get those errors after bringing up the interface and sending data, i have just now noticed these syslogd errors after using debug=6, before the card would slow, then lock, then the kernel would panic saying it could again the address would match the one from above. I am using tulip.c (v0.92), it is detecting the card only after loading the pci-scan module. ---- syslogd snip ---- kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker kernel: http://www.scyld.com/network/tulip.html kernel: eth0: ADMtek Comet rev 17 at 0xc482ac00, 00:20:78:01:5C:0F, IRQ 9. ---- end snip ---- Things i did wrong: 1. i bought a computer product from Future Shit. 2. buying one with such a gay name on the box. 3. not checking to see how well it was supported working. I would like any help that anyone could offer. Thanks, Chris Leavoy CyberPir8@EFNet ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From cyberpirate@cyberdude.com Tue May 9 22:41:25 2000 Date: Tue May 9 22:41:25 2000 From: Chris Leavoy cyberpirate@cyberdude.com Subject: Prolems with tulip driver I have recently purchased a Network Anywhere NC100 v2, Linksys Fast Ethernet 10/100 from future shit. I am having a whole bunch of problems with this card, and trying to get it working properly in linux with the tulip module driver. ---- syslogd snip ---- kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. kernel: eth0: exiting interrupt, csr5=0xfc264010. kernel: eth0: interrupt csr5=0xfc674015 new csr5=0xfc664010. kernel: eth0: exiting interrupt, csr5=0xfc664010. kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. kernel: eth0: exiting interrupt, csr5=0xfc264010. ---- end snip ---- I get those errors after bringing up the interface and sending data, i have just now noticed these syslogd errors after using debug=6, before the card would slow, then lock, then the kernel would panic saying it could again the address would match the one from above. I am using tulip.c (v0.92), it is detecting the card only after loading the pci-scan module. ---- syslogd snip ---- kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker kernel: http://www.scyld.com/network/tulip.html kernel: eth0: ADMtek Comet rev 17 at 0xc482ac00, 00:20:78:01:5C:0F, IRQ 9. ---- end snip ---- Things i did wrong: 1. i bought a computer product from Future Shit. 2. buying one with such a gay name on the box. 3. not checking to see how well it was supported working. I would like any help that anyone could offer. Thanks, Chris Leavoy CyberPir8@EFNet ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From cyberpirate@cyberdude.com Tue May 9 22:47:31 2000 Date: Tue May 9 22:47:31 2000 From: Chris Leavoy cyberpirate@cyberdude.com Subject: Problems with tulip driver I have recently purchased a Network Anywhere NC100 v2, Linksys Fast Ethernet 10/100 from future shit. I am having a whole bunch of problems with this card, and trying to get it working properly in linux with the tulip module driver. ---- syslogd snip ---- kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. kernel: eth0: exiting interrupt, csr5=0xfc264010. kernel: eth0: interrupt csr5=0xfc674015 new csr5=0xfc664010. kernel: eth0: exiting interrupt, csr5=0xfc664010. kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. kernel: eth0: exiting interrupt, csr5=0xfc264010. ---- end snip ---- I get those errors after bringing up the interface and sending data, i have just now noticed these syslogd errors after using debug=6, before the card would slow, then lock, then the kernel would panic saying it could again the address would match the one from above. I am using tulip.c (v0.92), it is detecting the card only after loading the pci-scan module. ---- syslogd snip ---- kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker kernel: http://www.scyld.com/network/tulip.html kernel: eth0: ADMtek Comet rev 17 at 0xc482ac00, 00:20:78:01:5C:0F, IRQ 9. ---- end snip ---- Things i did wrong: 1. i bought a computer product from Future Shit. 2. buying one with such a gay name on the box. 3. not checking to see how well it was supported working. I would like any help that anyone could offer. Thanks, Chris Leavoy CyberPir8@EFNet ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Wed May 10 03:43:33 2000 Date: Wed May 10 03:43:33 2000 From: Donald Becker becker@scyld.com Subject: Prolems with tulip driver On Tue, 9 May 2000, Chris Leavoy wrote: > I have recently purchased a Network Anywhere NC100 v2, Linksys Fast > Ethernet 10/100 from future shit. I am having a whole bunch of problems This obviously isn't a Linksys card. > ---- syslogd snip ---- > kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. > kernel: eth0: exiting interrupt, csr5=0xfc264010. > kernel: eth0: interrupt csr5=0xfc674015 new csr5=0xfc664010. > kernel: eth0: exiting interrupt, csr5=0xfc664010. > kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. > kernel: eth0: exiting interrupt, csr5=0xfc264010. That looks like normal operation. > I get those errors after bringing up the interface and sending data, i > have just now noticed these syslogd errors after using debug=6, before the > card would slow, then lock, then the kernel would panic saying it could > > again the address would match the one from above. You missed a few lines there. What did you mean to say? Keep in mind that the system will be very slow if you are synchronously logging message with debug=6! At the very least, set /etc/syslog.conf with a "-" in front of the log file name. > I am using tulip.c (v0.92), it is detecting the card only after loading > the pci-scan module. That is correct. The PCI scan module is now required to hide kernel differences, support hot-swap/CardBus, and handle power management. > ---- syslogd snip ---- > kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker > kernel: http://www.scyld.com/network/tulip.html > kernel: eth0: ADMtek Comet rev 17 at 0xc482ac00, 00:20:78:01:5C:0F, IRQ 9. Ahhh, you have an ADMtek Comet chip. This chip is relatively new. It should work correctly with my recent drivers, but will not even be detected with earlier Tulip drivers. I just plugged in a CardBus card based on the very similar ADMtek Centaur chip to send this message: it's very nearly identical to a Comet, but packaged for CardBus. If it work in a CardBus version, the PCI version almost certainly works. My laptop reports ________________ Found a ADMtek Centaur-C at 32/0 address 0xa0060000->0xc8034000 IRQ 10. ADMtek Centaur-C at 32/0 command 0x7. eth0: ADMtek Comet rev 17 at 0xc8034000, 00:00:E8:11:11:25, IRQ 10. ________________ The only buglet is that the mii-diag values are all '0'. I'll check that out later. I'll run my Comet PCI board and v92 through the normal tests tomorrow if I get a chance. > CyberPir8@EFNet How very '1337. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From tabt@gmx.de Wed May 10 06:49:56 2000 Date: Wed May 10 06:49:56 2000 From: Tobias Abt tabt@gmx.de Subject: Allnet 8832 almost working with v0.92 tulip driver Sorry for the long mail, but I tried to supply all necessary information. I own an Allnet 8832 ethernet card which uses a 21143 tulip chip set. It can use 100base-Tx (TP), 10base-T (TP) and 10base-2 (BNC). It identifies itself as: ------------------------ �lspci -vv� output: ------------------- 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) Subsystem: Cogent Data Technologies, Inc. ANA-6911A/TXC Fast Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- eth0: Digital DS21143 Tulip rev 48 at 0xc884c000, 00:E0:7D:70:05:1E, IRQ 10. eth0: EEPROM default media type Autosense. eth0: MII interface PHY 0, setup/reset sequences 2/3 long, capabilities 01 00. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block. eth0: Using media type MII, CSR12 is c6. eth0: ***WARNING***: No MII transceiver found! eth0: Restarting internal NWay autonegotiation, 0000ffbf. (Note: no MII tranceiver found, but it still works!?) tulip-diag -aa: --------------- tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xb800. Digital DS21143 Tulip chip registers at 0xb800: ffa08000 ffffffff ffffffff 03a2b800 03a2ba00 f0000102 320e0000 f3fe0000 e0000000 ffffcbf8 ffffffff fffe0000 000000c6 ffff0000 fff80000 8ff10000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. tulip-diag -mm: --------------- tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xb800. Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 1000 782d 7810 0001 01e1 0081 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 28c8 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000. Internal autonegotiation state is 'Autonegotiation disabled'. tulip-diag -ee: --------------- tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xb800. Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM size is 6. PCI Subsystem IDs, vendor 1109, device 2b00. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:E0:7D:70:05:1E. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 40, default media type 0800 (Autosense). 2 transceiver description blocks: Media MII, block type 3, length 23. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0001. 21143 MII reset sequence is 3 words: 0821 0001 0001. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. Media 10base2, block type 2, length 12. Serial transceiver for 10base2 (media type 65). CSR13 0009 CSR14 0705 CSR15 0003. GP pin direction 0821 GP pin data 0005. EEPROM contents: 1109 2b00 0000 0000 0000 0000 0000 0000 00b4 0103 e000 707d 1e05 2800 0000 0000 0000 0000 0000 0000 0800 9702 0003 2102 0108 0300 0821 0001 0001 7800 01e0 5000 1800 8c00 4102 0009 0705 0003 0821 0005 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 042b 6117 ID block CRC 0xb4 (vs. 0xb4). Full contents CRC 0x6117 (read as 0x6117). MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 1000 782d 7810 0001 01e1 0081 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 28c8 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000. Internal autonegotiation state is 'Autonegotiation disabled'. Short status: ------------- driver version | 100base-Tx 10base-T 10base-2 ----------------+-------------------------------------------------------- v0.89 | does not work does not work does not work v0.91g-ppc | does not work does not work works well v0.92 | works, but (1) works, but (1) works, but (1) 0.9.4.3 | does not work does not work works well And just for a reference that the opposite host works fine: Win98SE driver | works well works well works well (std. "Intel 21143/2-based 10/100mbps Ethernet Controller" driver that comes with Windows98 second edition - prior to that second edition it was called "DEC..."). (The opposite host was a linux-2.3.99-pre6 box with another tulip based card for 100base-Tx or a NE2k-pci based card for 10base-T and 10base-2; cable used for TP was a CAT5 crossover TP). Problem description: -------------------- (1): �Tx hung� and �Transmit timeout� problems regardless of interface used. symptoms: - FTP works in short fast bursts (one or two seconds at the most), then stops for a few (five or so) seconds, then the next burst; once I could transfer a 3 MB MP3 file in 0.3 seconds, but most times the transfer rate averaged about 200 kB/s for ~3-4 MB files using 100base-Tx. - NFS suffers more badly and only transfers about 40 kByte/s regardless of interface used. BTW, autodetection of interface does not work at all. I have to supply options=1 or 11 to get it working. Would be nicer though if it worked without as I often change the configuration for tests. :-) log file (example using MII interface with 100base-Tx with 2.2.15 kernel, debug level=3): ------------------------------------- May 10 07:02:40 banshee kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 10 07:02:40 banshee kernel: http://www.scyld.com/network/tulip.html May 10 07:02:40 banshee kernel: eth0: Digital DS21143 Tulip rev 48 at 0xc8858000, 00:E0:7D:70:05:1E, IRQ 10. May 10 07:02:40 banshee kernel: eth0: EEPROM default media type Autosense. May 10 07:02:40 banshee kernel: eth0: MII interface PHY 0, setup/reset sequences 2/3 long, capabilities 01 00. May 10 07:02:40 banshee kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. May 10 07:02:40 banshee kernel: eth0: Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block. May 10 07:02:40 banshee kernel: eth0: Using media type MII, CSR12 is c6. May 10 07:02:40 banshee kernel: eth0: ***WARNING***: No MII transceiver found! May 10 07:02:40 banshee kernel: eth0: Restarting internal NWay autonegotiation, 0000ffbf. May 10 07:02:40 banshee named[126]: XX+/127.0.0.1/banshee.tabtnet.de/PTR/IN May 10 07:02:40 banshee named[126]: XX+/127.0.0.1/banshee/PTR/IN May 10 07:02:40 banshee kernel: eth0: tulip_open() irq 10. May 10 07:02:40 banshee kernel: eth0: Using user-specified media MII. May 10 07:02:40 banshee kernel: eth0: Advertising 03e0 on MII 1. May 10 07:02:40 banshee kernel: eth0: Using media type MII, CSR12 is c6. May 10 07:02:40 banshee kernel: eth0: MII link partner ffff, negotiated 03e0. May 10 07:02:40 banshee kernel: eth0: Done tulip_open(), CSR0 ffa08000, CSR5 f0320000 CSR6 320e2002. May 10 07:02:43 banshee kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 10 07:02:43 banshee kernel: eth0: MII link partner 0081, negotiated 0080. May 10 07:03:27 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:03:27 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:03:37 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:03:37 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:03:43 banshee kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 10 07:03:43 banshee kernel: eth0: MII link partner 0081, negotiated 0080. May 10 07:03:43 banshee kernel: eth0: Tx hung, 14485 vs. 14475. May 10 07:03:43 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:03:43 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:03:52 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:03:52 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:04:02 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:04:02 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:04:12 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:04:12 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:04:22 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:04:22 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:04:32 banshee kernel: eth0: Transmit timeout using MII device. May 10 07:04:32 banshee kernel: eth0: The transmitter stopped. CSR5 is f0368002, CSR6 320e2002, new CSR6 20e0000. May 10 07:04:43 banshee kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 10 07:04:43 banshee kernel: eth0: MII link partner 0081, negotiated 0080. May 10 07:05:43 banshee kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 10 07:05:43 banshee kernel: eth0: MII link partner 0081, negotiated 0080. May 10 07:06:43 banshee kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 10 07:06:43 banshee kernel: eth0: MII link partner 0081, negotiated 0080. May 10 07:07:43 banshee kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 10 07:07:43 banshee kernel: eth0: MII link partner 0081, negotiated 0080. May 10 07:08:43 banshee kernel: eth0: N-Way autonegotiation status 000000c6, MII. May 10 07:08:43 banshee kernel: eth0: MII link partner 0081, negotiated 0080. May 10 07:09:04 banshee kernel: eth0: Shutting down ethercard, status was f0660000. ------------------------------------- If you need anything else or want me to debug new driver versions, just tell me. Thank you! Bye, \|/ Tobias @ @ +----------------oOO-(_)-OOo-----------+ | Tobias Abt | | email: tabt@gmx.de | +--------------------------------------+ ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From dixon@webwork.co.uk Wed May 10 08:33:21 2000 Date: Wed May 10 08:33:21 2000 From: Tim Dixon dixon@webwork.co.uk Subject: More DFE-570TX Tx Hung Problems [Just to summarise; we've been getting "Tx Hung" errors where we have several DFE-570TXs in one box so that some of the ports end up sharing IRQs. Simply ifconfig'ing the stuck port up and down makes no difference. Other ports on the same card continue to work. ] This gets more intriguging! We've just had this problem occurring again a couple of times in quick succession. As Donald predicted, /proc/interrupts revealed that no interrupts were being taken on the IRQ shared by the ports concerned. Although ifconfiging down the stuck port didn't make any difference, taking down ALL the ports sharing the IRQ and bringing them back up again seemed to do the trick. We've had the same problem on a couple of different IRQ lines in the same machine (in each case, 3 ports shared an IRQ). Looks like one of the devices is disabling the interrupt line and failing to re-enable it, taking out all of the others. Is the remedy for this likely to be in the driver, or might it be a strange kernel or hardware problem? Tim ---- WebWork Division TDC Networking Consultancy Design Works William Street Gateshead GB - NE10 0JP Tel: +44 (0) 191 422 2232 Fax: +44(0) 191 422 2233 Web: www.webwork.co.uk ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From cyberpir8@cyberpir8.yi.org Wed May 10 15:08:33 2000 Date: Wed May 10 15:08:33 2000 From: Chris Leavoy cyberpir8@cyberpir8.yi.org Subject: Prolems with tulip driver It was my first time posting to a mailing list, could you tell? ;) anyways i think i should give it another try. >> I have recently purchased a Network Anywhere NC100 v2, Linksys Fast >> Ethernet 10/100 from future shit. I am having a whole bunch of problems >This obviously isn't a Linksys card. It says Linksys right on the box, driver disk, and on the chip. This is a brand new card mind you, I think Linksys merged or split with another company called Network Everywhere, networkeverywhere.com >> ---- syslogd snip ---- >> kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. >> kernel: eth0: exiting interrupt, csr5=0xfc264010. >> kernel: eth0: interrupt csr5=0xfc674015 new csr5=0xfc664010. >> kernel: eth0: exiting interrupt, csr5=0xfc664010. >> kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. >> kernel: eth0: exiting interrupt, csr5=0xfc264010. >That looks like normal operation. That error message is put out on the screen at the fastest rate at which my system can handle it. I seriously doubt that is normal considering that it continues for 2 minutes after i have stopped transfering of a 1meg or so file. Now the part i forgot to include in the other message was that after a few minutes of transfering data over the card the system would hang. I would check syslogd and it reported that the kernel has paniced. I read up a few lines more and i get an error message saying, "unable to handle paging requests to virtual address 0xfc264010" or something close to that, i cant get a print out of it because the system requires a hard reboot after this happens. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Wed May 10 16:13:32 2000 Date: Wed May 10 16:13:32 2000 From: Donald Becker becker@scyld.com Subject: Prolems with tulip driver On Wed, 10 May 2000, Chris Leavoy wrote: > It was my first time posting to a mailing list, could you tell? ;) > > anyways i think i should give it another try. > > >> I have recently purchased a Network Anywhere NC100 v2, Linksys Fast > >> Ethernet 10/100 from future shit. I am having a whole bunch of problems > > >This obviously isn't a Linksys card. > > It says Linksys right on the box, driver disk, and on the chip. This is a > brand new card mind you, I think Linksys merged or split with another > company called Network Everywhere, networkeverywhere.com This is very surprising -- we just bought a bunch of Linksys 5 port switch kits, and each box came with a pair of PNIC-II cards with very recent dates. I didn't think they would be changing chips. > >> kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. > >> kernel: eth0: exiting interrupt, csr5=0xfc264010. > > >That looks like normal operation. > > That error message is put out on the screen at the fastest rate at which my > system can handle it. I seriously doubt that is normal considering that it > continues for 2 minutes after i have stopped transfering of a 1meg or so > file. Now the part i forgot to include in the other message was that after You turned debugging on, and didn't enabled write-behind in the /etc/syslog.conf. > a few minutes of transfering data over the card the system would hang. I > would check syslogd and it reported that the kernel has paniced. I read up > a few lines more and i get an error message saying, "unable to handle paging > requests to virtual address 0xfc264010" or something close to that, i cant > get a print out of it because the system requires a hard reboot after this > happens. What process died? Try running ksymoops. This doesn't sound like a typical Ethernet driver problem. I just tried my Comet PCI card and it seems to work fine. I'm in the process of putting a bunch of packet through the system. I have about a million packets through it so far, and I'll run it overnight. I have updated the v92 tulip driver to correctly handle the built-in MII transceiver of the Centaur (Comet on CardBus), but the change is minor so I'll wait for a few more changes before doing a new test release. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From cyberpir8@cyberpir8.yi.org Wed May 10 16:49:32 2000 Date: Wed May 10 16:49:32 2000 From: Chris Leavoy cyberpir8@cyberpir8.yi.org Subject: Prolems with tulip driver > > >> kernel: eth0: interrupt csr5=0xfc274014 new csr5=0xfc264010. > > >> kernel: eth0: exiting interrupt, csr5=0xfc264010. > > > > >That looks like normal operation. > > > > That error message is put out on the screen at the fastest rate at which my > > system can handle it. I seriously doubt that is normal considering that it > > continues for 2 minutes after i have stopped transfering of a 1meg or so > > file. Now the part i forgot to include in the other message was that after > > You turned debugging on, and didn't enabled write-behind in the > /etc/syslog.conf. It is enabled. The problem is not with my system. I think that there is something different with my nic that is causing problems with the tulip driver > > a few minutes of transfering data over the card the system would hang. I > > would check syslogd and it reported that the kernel has paniced. I read up > > a few lines more and i get an error message saying, "unable to handle paging > > requests to virtual address 0xfc264010" or something close to that, i cant > > get a print out of it because the system requires a hard reboot after this > > happens. > > What process died? Try running ksymoops. > This doesn't sound like a typical Ethernet driver problem. No process died. The kernel paniced. The system locked hard, *nothing* would respond. I just tried it again, but this time i turned off debuging mode (debug=0). After a few minutes of transfering the card locked. With the same error as before, "unable to handle paging requests to virtual address blah". The cards dos diag problem and network test feature that says the card is working perfectly in 100mbit full duplex mode. > I just tried my Comet PCI card and it seems to work fine. I'm in the > process of putting a bunch of packet through the system. I have about a > million packets through it so far, and I'll run it overnight. > > I have updated the v92 tulip driver to correctly handle the built-in MII > transceiver of the Centaur (Comet on CardBus), but the change is minor so > I'll wait for a few more changes before doing a new test release. ./tulip-diag -p 0xec00 -t 12 -aa -e -mm tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Assuming a ADMtek AL981 Comet adapter at 0xec00. ADMtek AL981 Comet chip registers at 0xec00: fff98000 ffffffff ffffffff 015c1000 015c1200 fc06c812 ffb70115 fffe4010 fffe0000 fff0dff8 00000000 fffe0000 00000000 00000200 00000000 c40ffec8 2006c812 804c0004 00000000 015c1010 f0000000 ffff0f5c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. Interrupt sources are pending! CSR5 is fc06c812. Tx complete indication. Link passed indication. Timer expired indication. Early Rx indication. The Comet MAC registers are 01782000 ffff0f5c filter 8000000000000000. EEPROM size is 8. A simplifed EEPROM data table was found. The EEPROM does not contain transceiver control information. No MII transceivers found! I find the last line of that output very interesting. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Wed May 10 18:53:19 2000 Date: Wed May 10 18:53:19 2000 From: Donald Becker becker@scyld.com Subject: More DFE-570TX Tx Hung Problems On Wed, 10 May 2000, Tim Dixon wrote: > [Just to summarise; we've been getting "Tx Hung" errors where we have > several DFE-570TXs in one box so that some of the ports end up > sharing IRQs. Simply ifconfig'ing the stuck port up and down makes > no difference. Other ports on the same card continue to work. ] ... > We've just had this problem occurring again a couple of times in quick > succession. As Donald predicted, /proc/interrupts revealed that no > interrupts were being taken on the IRQ shared by the ports concerned. > Although ifconfiging down the stuck port didn't make any difference, > taking down ALL the ports sharing the IRQ and bringing them back up > again seemed to do the trick. We've had the same problem on a couple > of different IRQ lines in the same machine (in each case, 3 ports shared > an IRQ). This is a critical detail: one possible cause is that the interrupt is being disabled, and never re-enabled. My code never does this, but some of the modifications of my drivers use this as a flow control and exclusion mechanism. > Looks like one of the devices is disabling the interrupt line and failing to > re-enable it, taking out all of the others. Is the remedy for this likely to > be > in the driver, or might it be a strange kernel or hardware problem? Which driver were you using again? Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From jgarzik@mandrakesoft.mandrakesoft.com Wed May 10 21:38:58 2000 Date: Wed May 10 21:38:58 2000 From: Jeff Garzik jgarzik@mandrakesoft.mandrakesoft.com Subject: More DFE-570TX Tx Hung Problems On Wed, 10 May 2000, Donald Becker wrote: > This is a critical detail: one possible cause is that the interrupt is being > disabled, and never re-enabled. My code never does this, but some of the > modifications of my drivers use this as a flow control and exclusion > mechanism. Can you be more specific -- do any in the 2.2.x or 2.3.x kernels do this? That should be stamped out, and fast. Jeff ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From danci@kibla.org Thu May 11 02:37:22 2000 Date: Thu May 11 02:37:22 2000 From: Danilo Godec danci@kibla.org Subject: Alphas and Tulip v0.92 Is tulip.c v0.92 supposed to compile on an alpha platform with 2.2.15 kernel? If I try to 'gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c tulip.c' I get this: tulip.c:161: pci-scan.h: No such file or directory tulip.c:162: kern_compat.h: No such file or directory But if I try to copy it to kernel source tree in the place of the old tulip.c and then do a 'make modules', I get a lot of warnings and finnaly an error. Where do pci-scan.h and kern_compat.h come from? I have RedHat 6.1 and 2.2.15 kernel on an Alpha 164SX. Thanks, D. [ "2b" || ! "2b" ] ? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From toby@earth.li Thu May 11 08:40:36 2000 Date: Thu May 11 08:40:36 2000 From: Toby Jaffey toby@earth.li Subject: Driver problems with LNE100TX v4 (admtek comet) I am having problems getting the tulip driver to recognise my card. My machine: Dual Celeron 500s, 64mb, Rage Pro. Under 2.3.99-pre6 (with SMP), it works fine, the tulip module comes up as an "admtek comet". However, I haven't been able to get it working (with or without SMP) in 2.0.36, 2.2.13, 2.2.15 or 2.3.51 (that's all I've tried). I tried using tulip.c 0.91g, but that didn't help. I would really rather not run 2.3.99-pre6.. so, can anyone suggest how I might get the card to recognise under an earlier kernel? -- : www.nott.ac.uk/~psystj/ : Cogito ergo sum machine : : Never test for an error you don't know how to )\._.,--....,'``. : handle. /, _.. \ _\ ;`._ ,. : `._.-(,_..'--(,_..'`-.;.' ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Thu May 11 11:18:42 2000 Date: Thu May 11 11:18:42 2000 From: Donald Becker becker@scyld.com Subject: Driver problems with LNE100TX v4 (admtek comet) On Thu, 11 May 2000, Toby Jaffey wrote: > Subject: Driver problems with LNE100TX v4 (admtek comet) > > I am having problems getting the tulip driver to recognise my card. .. > I would really rather not run 2.3.99-pre6.. so, can anyone suggest how I might Use the drivers at http://www.scyld.com/network/index.html Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Thu May 11 11:30:42 2000 Date: Thu May 11 11:30:42 2000 From: Donald Becker becker@scyld.com Subject: Alphas and Tulip v0.92 On Thu, 11 May 2000, Danilo Godec wrote: > Is tulip.c v0.92 supposed to compile on an alpha platform with 2.2.15 > kernel? Yes. With some sets of include files you will get warnings about inl() returning a 'long' instead of an 'int'. These warnings are harmless. (Grrrr, what a bogus change: inl() returns a 32 bit value. There is no reason to make it a 'long'.) > If I try to 'gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c tulip.c' I get > this: > > tulip.c:161: pci-scan.h: No such file or directory > tulip.c:162: kern_compat.h: No such file or directory Read http://www.scyld.com/network/index.html > But if I try to copy it to kernel source tree in the place of the old > tulip.c and then do a 'make modules', I get a lot of warnings and finnaly > an error. > > Where do pci-scan.h and kern_compat.h come from? The same place you got the updated driver from. This change was forced by Linus about ten months ago, when he rejected driver changes that had backwards compatibility in the code. So I went off and spent two months working on a scheme to isolate the kernel compatibility code, and test all of the drivers with the new scheme. When it was finished, Linus once again rejected the new versions... Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From toby@earth.li Thu May 11 16:15:04 2000 Date: Thu May 11 16:15:04 2000 From: Toby Jaffey toby@earth.li Subject: Driver problems with LNE100TX v4 (admtek comet) On Thu, May 11, 2000 at 11:20:18AM -0400, Donald Becker wrote: > On Thu, 11 May 2000, Toby Jaffey wrote: > > Subject: Driver problems with LNE100TX v4 (admtek comet) > > I am having problems getting the tulip driver to recognise my card. > Use the drivers at > http://www.scyld.com/network/index.html Thanks, worked perfectly. -- (o_ | Toby Jaffey : www.nott.ac.uk/~psystrj/ //\ | The face of a child can say it all, especially the mouth part of the V_/_ | face. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From epop@stanford.edu Thu May 11 20:58:17 2000 Date: Thu May 11 20:58:17 2000 From: Eric Pop epop@stanford.edu Subject: setting 100baseTx-FD Hi all. I've got an ethernet card based on the Digital 21143 chipset and I'm using the tulip.c:v0.91g-ppc 7/16/99 driver (kernel 2.2.14 on a red hat install). Recently my dorm's network was upgraded to 100baseT ethernet so I thought it might be nice to take advantage of this. So I brought down the network interface and removed the tulip kernel module. Then I ran insmod insmod /lib/modules/2.2.14-12/net/tulip.o options=5 /etc/rc.d/init.d/network start But tulip-diag -e still reports a 10mpbs connection: tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x2000. Port selection is 10mpbs-serial, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. The NWay status register is 45e1d2ca. EEPROM size is 6. PCI Subsystem IDs, vendor 0e11, device b0bb. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:40:D0:0B:40:74. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 2 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08e1 GP pin data 0000. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08e1 GP pin data 0000. Internal autonegotiation state is 'Negotiation complete'. while mii-diag reports: Using the default interface 'eth0'. Basic registers of MII PHY #32: 1000 786c 0000 0000 04a1 45e1 0000 0000. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. What am I missing or doing wrong? How can I tell my card to run at 100baseT? Any suggestions? Thank you. Sincerely, Eric Pop. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Thu May 11 21:42:39 2000 Date: Thu May 11 21:42:39 2000 From: Donald Becker becker@scyld.com Subject: setting 100baseTx-FD On Thu, 11 May 2000, Eric Pop wrote: > Hi all. I've got an ethernet card based on the Digital 21143 chipset and > I'm using the tulip.c:v0.91g-ppc 7/16/99 driver (kernel 2.2.14 on a red hat > install). Recently my dorm's network was upgraded to 100baseT ethernet so > I thought it might be nice to take advantage of this. So I brought down the > network interface and removed the tulip kernel module. Then I ran > > insmod insmod /lib/modules/2.2.14-12/net/tulip.o options=5 Forcing the media here is bad -- see below. > But tulip-diag -e still reports a 10mpbs connection: > tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Digital DS21143 Tulip adapter at 0x2000. ... > The NWay status register is 45e1d2ca. Your link partner is a very capable switch that wants to autonegotiate. http://scyld.com/expert/NWay.html You should let it. By forcing the media type you are preventing autonegotiation, and thus causing the switch to believe that you are half duplex mode. > Port selection is 10mpbs-serial, full-duplex. Hmmm, this is curious. Something unexpected is going on. One of the changes to the v92 (vs. 91g) driver is paying stricter attention to the forced media type flag on the 21143, while still using the EEPROM media table. I would normally recommend that you try v92, but the best solution is to just not force the media type. > EEPROM transceiver/media description for the Digital DS21143 Tulip chip. > Leaf node at offset 30, default media type 0800 (Autosense). > 2 transceiver description blocks: > Media 10baseT, block type 2, length 6. > Serial transceiver for 10baseT (media type 0). > GP pin direction 08e1 GP pin data 0000. > Media 10baseT-Full Duplex, block type 2, length 6. > Serial transceiver for 10baseT-Full Duplex (media type 4). > GP pin direction 08e1 GP pin data 0000. Ahhh, this might be a problem. The 21143 media table only has 10baseT types! The driver *was* doing the best that it could. Does your card really support 100baseTx? > Internal autonegotiation state is 'Negotiation complete'. > while mii-diag reports: > > Using the default interface 'eth0'. > Basic registers of MII PHY #32: 1000 786c 0000 0000 04a1 45e1 0000 0000. The driver is "faking" these registers, and doesn't do a perfect job of it. > Basic mode control register 0x1000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx > 10baseT-FD 10baseT, w/ 802.3X flow control. > > What am I missing or doing wrong? How can I tell my card to run at 100baseT? > Any suggestions? Thank you. It's possible to force the setting, but the correct solution is to find out why the EEPROM is reporting only 10baseT media types. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From homer@lightlink.com Fri May 12 00:36:19 2000 Date: Fri May 12 00:36:19 2000 From: Homer Wilson Smith homer@lightlink.com Subject: setting 100baseTx-FD > > insmod insmod /lib/modules/2.2.14-12/net/tulip.o options=5 > > Forcing the media here is bad -- see below. The same thing happens with the Kingston KNE100TX, the Cisco Switch doesn't have autonegotiate for the 10baseT ports, only forced FULL and Half. If the Switch is in Full, the card will not autonegotiate (v92 as recommened) but stays in half duplex. Homer > > > But tulip-diag -e still reports a 10mpbs connection: > > tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a Digital DS21143 Tulip adapter at 0x2000. > ... > > The NWay status register is 45e1d2ca. > > Your link partner is a very capable switch that wants to autonegotiate. > http://scyld.com/expert/NWay.html > You should let it. > > By forcing the media type you are preventing autonegotiation, and thus > causing the switch to believe that you are half duplex mode. > > > Port selection is 10mpbs-serial, full-duplex. > > Hmmm, this is curious. Something unexpected is going on. > > One of the changes to the v92 (vs. 91g) driver is paying stricter attention > to the forced media type flag on the 21143, while still using the EEPROM > media table. I would normally recommend that you try v92, but the best > solution is to just not force the media type. > > > EEPROM transceiver/media description for the Digital DS21143 Tulip chip. > > Leaf node at offset 30, default media type 0800 (Autosense). > > 2 transceiver description blocks: > > Media 10baseT, block type 2, length 6. > > Serial transceiver for 10baseT (media type 0). > > GP pin direction 08e1 GP pin data 0000. > > Media 10baseT-Full Duplex, block type 2, length 6. > > Serial transceiver for 10baseT-Full Duplex (media type 4). > > GP pin direction 08e1 GP pin data 0000. > > Ahhh, this might be a problem. The 21143 media table only has 10baseT > types! The driver *was* doing the best that it could. Does your card > really support 100baseTx? > > > Internal autonegotiation state is 'Negotiation complete'. > > > while mii-diag reports: > > > > Using the default interface 'eth0'. > > Basic registers of MII PHY #32: 1000 786c 0000 0000 04a1 45e1 0000 0000. > > The driver is "faking" these registers, and doesn't do a perfect job of it. > > > Basic mode control register 0x1000: Auto-negotiation enabled. > > You have link beat, and everything is working OK. > > Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx > > 10baseT-FD 10baseT, w/ 802.3X flow control. > > > > What am I missing or doing wrong? How can I tell my card to run at 100baseT? > > Any suggestions? Thank you. > > It's possible to force the setting, but the correct solution is to find out > why the EEPROM is reporting only 10baseT media types. > > Donald Becker becker@scyld.com > Scyld Computing Corporation > 410 Severn Ave. Suite 210 > Annapolis MD 21403 > > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-tulip-request@beowulf.org > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From epop@stanford.edu Fri May 12 13:48:48 2000 Date: Fri May 12 13:48:48 2000 From: Eric Pop epop@stanford.edu Subject: setting 100baseTx-FD > One of the changes to the v92 (vs. 91g) driver is paying stricter attention > to the forced media type flag on the 21143, while still using the EEPROM > media table. I would normally recommend that you try v92, but the best > solution is to just not force the media type. So... should I give v92 a try? If the EEPROM is reporting only 10baseT media types then that won't do me any good, will it? > Ahhh, this might be a problem. The 21143 media table only has 10baseT > types! The driver *was* doing the best that it could. Does your card > really support 100baseTx? Well... that's what it was advertised as. Though on the other hand I have to admit that my machine is one of those Compaq's with everything (e.g sound card, video card and ethernet) integrated onto the motherboard. So I don't really know what kind of "card" it is, except for the fact that in Windoze ControlPanels/Network/NetworkComponents I see two relevant items listed: "Compaq NC3120 Fast Ethernet NIC" and "Intel 21143/2 based 10/100 mbps Ethernet Controller". > It's possible to force the setting, but the correct solution is to find out > why the EEPROM is reporting only 10baseT media types. Is there a way I can find out *for sure* if this card really supports 100mbps Ethernet? If so and if the EEPROM settings are funny -- can I rewrite them and still convince the card to operate at 100mpbs-FD? Btw, I don't know if this offers any more clues, but as soon as they switched my network to 100mpbs capability on Monday morning my connection went down. I wasn't able to reestablish it until 48 hours later (doh!) when after many trials and error I upgraded the tulip driver to v0.91g (from the original v0.89H that came with RedHat6.1). I wonder what changes between the two driver versions made my network connection possible again?! Finally, here's the relevant part of /var/log/messages when the machine boots: kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov kernel: eth0: Digital DS21143 Tulip rev 65 at 0x2000, 00:40:D0:0B:40:74, IRQ 10. kernel: eth0: EEPROM default media type Autosense. kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. kernel: eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Thanks in advance for any other thoughts. -Eric ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From becker@scyld.com Fri May 12 16:44:09 2000 Date: Fri May 12 16:44:09 2000 From: Donald Becker becker@scyld.com Subject: setting 100baseTx-FD On Fri, 12 May 2000, Eric Pop wrote: > Subject: Re: setting 100baseTx-FD > > > One of the changes to the v92 (vs. 91g) driver is paying stricter attention > > to the forced media type flag on the 21143, while still using the EEPROM > > media table. I would normally recommend that you try v92, but the best > > solution is to just not force the media type. > > So... should I give v92 a try? If the EEPROM is reporting only 10baseT media > types then that won't do me any good, will it? Correct. If the media table doesn't have an entry, you don't know how to configure the "GP" pins. > > Ahhh, this might be a problem. The 21143 media table only has 10baseT > > types! The driver *was* doing the best that it could. Does your card > > really support 100baseTx? > > Well... that's what it was advertised as. Though on the other hand I have > to admit that my machine is one of those Compaq's with everything (e.g sound > card, video card and ethernet) integrated onto the motherboard. So I don't > really know what kind of "card" it is, except for the fact that in Windoze Was it advertised as 10/100, or only "Ethernet"? The 21143 needs extra chips to do 100baseTx, and Compaq might have omitted them from the design. > > It's possible to force the setting, but the correct solution is to find out > > why the EEPROM is reporting only 10baseT media types. > > Is there a way I can find out *for sure* if this card really supports 100mbps > Ethernet? Yes. Trace out the design on the motherboard and compare it to the 21143 manual. That's a lot of work. If you know what to look for, you could look for the "twister" chip near the magnetics. It's easiest for most people to look in the manual for the system. > If so and if the EEPROM settings are funny -- can I rewrite them > and still convince the card to operate at 100mpbs-FD? Yup. The 'tulip-diag' program (shhhh, don't tell anyone) already has code to write media tables, and a media table for the Intel CardBus card. I've written a page on writing media tables at http://www.scyld.com/network/tulip-media.html > Btw, I don't know if this offers any more clues, but as soon as they switched > my network to 100mpbs capability on Monday morning my connection went down. > I wasn't able to reestablish it until 48 hours later (doh!) when after many > trials and error I upgraded the tulip driver to v0.91g (from the original > v0.89H that came with RedHat6.1). I wonder what changes between the two > driver versions made my network connection possible again?! The problem was that earlier drivers assumed all 21143 cards could handle both 10 and 100Mbps, and always advertised 0x01e1. The updated driver now builds the to-advertise value based on the media table, specifically to support 21143 cards that don't have all transceiver types available. > kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov > kernel: eth0: Digital DS21143 Tulip rev 65 at 0x2000, 00:40:D0:0B:40:74, IRQ > 10. > kernel: eth0: EEPROM default media type Autosense. > kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY > (2) block. > kernel: eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial > PHY (2) block. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From wilesjc@ipa.net Fri May 12 17:16:20 2000 Date: Fri May 12 17:16:20 2000 From: Jacob Wiles wilesjc@ipa.net Subject: echo subscribe | /bin/mail linux-tulip-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-tulip-request@beowulf.org From sdarveau@imt.ca Tue, 16 May 2000 09:19:27 -0500 Date: Tue, 16 May 2000 09:19:27 -0500 From: Stephane Darveau sdarveau@imt.ca Subject: [tulip] Component Information This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BFBF17.D5B3B2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good Day, My name is Stephane Darveau and I am currently employed at Info = Magnetics Technologies in Winnipeg. I am researching potential parts = for an upcoming project involving ethernet transmission, and was hoping = you could send me a datasheet as well as a price quote for your DEC = 21140 tulip ethernet controller chip. Please contact me via email at = sdarveau@imt.ca for any questions or comments. I look forward to hearing from you, Stephane Darveau ------=_NextPart_000_0005_01BFBF17.D5B3B2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Good Day,

My name is Stephane Darveau and I am = currently=20 employed at Info Magnetics Technologies in Winnipeg. I am = researching=20 potential parts for an upcoming project involving ethernet transmission, = and was=20 hoping you could send me a datasheet as well as a price quote for your = DEC 21140=20 tulip ethernet controller chip. Please contact me via email at sdarveau@imt.ca for any questions or = comments.

I look forward to hearing from = you,

Stephane = Darveau

------=_NextPart_000_0005_01BFBF17.D5B3B2E0-- From rcm@bcnartdirecte.com Tue, 16 May 2000 23:57:25 +0200 Date: Tue, 16 May 2000 23:57:25 +0200 From: Rafael Cordones Marcos rcm@bcnartdirecte.com Subject: [tulip] Xircom CBEM support Hi, Is anybody working on Xircom CBEM support in tulip.c? I have a Xircom RBEM56G-100 and the network part doesn't work with the latest pcmcia package. The tulip driver I am using is: -------------------------------------------------------------------------- May 15 08:29:24 moebius kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) May 15 08:29:24 moebius kernel: eth0: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at 0x200, 00:10:A4:FA:92:69, IRQ 9. -------------------------------------------------------------------------- Thanks, Rafa P.S. danilo@cs.uni-magdeburg.de has not answered yet an email I sent him last week. -- Linux! The Choice of a GNU Generation! -> http://www.debian.org From becker@scyld.com Wed, 17 May 2000 04:13:40 -0400 (EDT) Date: Wed, 17 May 2000 04:13:40 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip] Component Information On Tue, 16 May 2000, Stephane Darveau wrote: > My name is Stephane Darveau and I am currently employed at Info Magnetics > Technologies in Winnipeg. I am researching potential parts for an > upcoming project involving ethernet transmission, and was hoping you could > send me a datasheet as well as a price quote for your DEC 21140 tulip > ethernet controller chip. You missed the point of this mailing list: to discuss issues relating to Linux drivers for the Tulip chip, and the many work-alikes. I can answer part of the question: The 21140 chip was End-Of-Lifed last year. AFAIK, no commercial quantities are available. The suggested replacement is the 21143, which has an uncertain future. Most board vendors are building around the following work-almost-alike chips ADMtek Comet/Centaur LiteOn PNIC-II Macronx 98713/98715/98725 Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 From poly@mail.sisna.com Wed, 17 May 2000 17:45:34 -0600 Date: Wed, 17 May 2000 17:45:34 -0600 From: Poly poly@mail.sisna.com Subject: [tulip] Linksys Network Card not working Dear Tulip List Members, I am hoping that someone can help me with the following: I have a Lynksys LNE 100 TX Fast Ethernet Adaptor (Version 2 with WakeUp-On-Line feature) on my PC, an HP 6640C, which has a AMD K6-2/500MHz 3DNow Processor. I have set it up as a Dual Boot, Windows98 or Linux, Red Hat 6.2. As a Windows Machine, there is no problem, and it talks well with my other machine, an old Pentium 166 with Windows95. When it boots as Linux Machine, the Red Hat 6.2 recognises the Network Card, uses tulip.c for it, and correctly sets the I/O 1400-14ff. But it does not work. When I do the ifconfig command, it says: SIOCSIFFLAGS: Resource Temporary Unavailable. It did not make much sense to try route, but I did and it also said: SIOCADDRT: Network is down. My question is, what to do now? I will be very grateful for any answer. I read as much as I could understand on the problem, and also checked my system. Below is more information that I found useful, on the IRQs and in the /var/log/messages. Thanks very much for the help. Poly. Please read on... In /var/log/messages, I found the following suspicious lines: The PCI BIOS has not enabled the device at 0/96 updating PCI Command 0083 to 0087 tulip.c :v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: Lite-on PNIC-II rev 37 at 0x1400, 00:A0:CC :37:95:B8, IRQ 0 Below is the Interrupt Request from Red Hat Information IRQ CPUO 0 51951 XT-PIC timer 1 36 XT-PIC keyboard 2 0 XT-PIC cascade 8 1 XT-PIC rtc 12 6684 XT-PIC PS/2 Mouse 13 0 XT-PIC fpu 14 100231 XT-PIC ide0 15 3348 XT-PIC ide1 NMI 0 >From cat /proc/pci I found: IRQ 9 VGA Adapter IRQ 11 USB Also from some other file: IRQ 4 ttyS00 at 0x03f8 On the Windows98 side, the IRQs are as follows: 00 Timer 01 Keyboard 02 Programmable Interrupt Control 03 Com2 04 Com1 06 Standard Floppy 07 Printer Port LPT1 08 System CMOS/Real Time Clock 09 ACPI IRQ Holder for PCI IRQ Steering 09 Linksys LNE 100TX Fast Ethernet Adaptor 09 SiS 530 (VGA Adaptor) 10 ACPI IRQ Holder for PCI IRQ Steering 10 Conexant PCI Modem Emulator 10 Master Riptide PCI Audio Device 11 ACPI IRQ Holder for PCI IRQ Steering 11 ACPI IRQ Holder for PCI IRQ Steering - again 11 SiS 7001 PCI to USB Open Host Controller 11 SCI IRQ used by ACPI bus 12 PS/2 compatible Mouse Port 14 SiS 5513 Dual PCI IDE Controller 14 Primary IDE Dual FIFO 15 SiS 5513 Dual PCI IDE Controller 15 Secondary IDE Controller Dual FIFO Thanks again. From d.hartman@student.utwente.nl Thu, 18 May 2000 02:36:30 +0200 Date: Thu, 18 May 2000 02:36:30 +0200 From: The DJ d.hartman@student.utwente.nl Subject: [tulip] Farallon card i have a farallon Fast Ether TX-10/100 PN996 PCI card with DEC21143 chipset. What are the changes the Tulip driver will work on this card? Derk-Jan Hartman From becker@scyld.com Wed, 17 May 2000 21:17:08 -0400 (EDT) Date: Wed, 17 May 2000 21:17:08 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip] Re: Linksys Network Card not working On Wed, 17 May 2000, Poly wrote: > In /var/log/messages, I found the following suspicious lines: > The PCI BIOS has not enabled the device at 0/96 > updating PCI Command 0083 to 0087 > tulip.c :v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov > eth0: Lite-on PNIC-II rev 37 at 0x1400, 00:A0:CC > :37:95:B8, IRQ 0 IRQ 0 Read http://www.scyld.com/expert/irq-conflict.html Windows said > 09 ACPI IRQ Holder for PCI IRQ Steering > 09 Linksys LNE 100TX Fast Ethernet Adaptor Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 From becker@scyld.com Wed, 17 May 2000 21:18:52 -0400 (EDT) Date: Wed, 17 May 2000 21:18:52 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip] Farallon card On Thu, 18 May 2000, The DJ wrote: > i have a farallon Fast Ether TX-10/100 > PN996 PCI card with DEC21143 chipset. > What are the changes the Tulip driver will work on this card? The v91g or v91g-ppc driver in recent 2.2 kernels should work. The v92 driver almost certainly will work. http://www.scyld.com/network/tulip.html ftp://www.scyld.com/pub/network/tulip.c Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 From j.stifter@medres.ch Thu, 18 May 2000 11:28:24 +0200 Date: Thu, 18 May 2000 11:28:24 +0200 From: Jan Stifter j.stifter@medres.ch Subject: [tulip] Farallon card On Thu, 18 May 2000 02:36:30 +0200, The DJ wrote: >i have a farallon Fast Ether TX-10/100 >PN996 PCI card with DEC21143 chipset. >What are the changes the Tulip driver will work on this card? hi there, i am using the same card here for various linux systems. i took the driver: static const char version[] = "tulip.c:v0.91g 7/16/99 and copied it directly in the kernel source. it worked for me even for kernel 2.0.35 hope it helps jan --- >I placed the following in my rc.local file and it is creating havoc. Try "rm havoc". from the qmail mailing-list. From homer@lightlink.com Thu, 18 May 2000 19:09:30 -0400 (EDT) Date: Thu, 18 May 2000 19:09:30 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] 21143 Donald, Is there any hope of getting the 21143 to do full duplex with a Cisco 1900 using v91-92? I am at my wits end here and have to do something fast. Thanks Homer ------------------------------------------------------------------------ Homer Wilson Smith Clear Air, Clear Water, Art Matrix - Lightlink (607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY homer@lightlink.com Is that too much to ask? http://www.lightlink.com From becker@scyld.com Fri, 19 May 2000 00:50:54 -0400 (EDT) Date: Fri, 19 May 2000 00:50:54 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip] Re: Digital Tulip Design On Mon, 8 May 2000, Homer Wilson Smith wrote: > > > I was not able to get v92g to run in linux 2.0.36. > > You don't have 'pci-scan.o' loaded. > This worked beautifully, still no FD on 21143 Kingstons. > Using insmod tulip options=x AFTER pci_scan is loaded, > the only options that tulip diag reports as full duplex are > 4,5,8,10,26 and 27. Hmmm, did you try #14? This should set MII- 100baseTx-FD > Perhaps it is a problem with Cisco 1900 Switches in Full Dup mode? Ciscos switches frequently have broken autonegotiation. > May 10 19:25:46 jane kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker > May 10 19:25:46 jane kernel: http://www.scyld.com/network/tulip.html > May 10 19:25:46 jane kernel: eth0: Digital DS21143 Tulip rev 65 at 0x2820000, 00:40:F0:4C:E6:A9, IRQ 11. > May 10 19:25:46 jane kernel: eth0: EEPROM default media type Autosense. > May 10 19:25:46 jane kernel: eth0: Index #0 - Media MII 100baseTx (#13) > described by a 21140 non-MII (0) block. Huh? That's not right. It should be just "MII transceiver". I have what I believe is an identical board that has no problem with v0.92 > May 10 19:25:46 jane kernel: eth0: MII transceiver #1 config 3100 status > 782d advertising 03e0. > Media MII, block type 3, length 13. > MII interface PHY 0 (media type 11). That looks normal. > 2646 0001 0000 0000 0000 0000 0000 0300 > 10a6 0104 c000 4cf0 a9e6 1e00 0000 0800 > 8d01 0003 0000 7800 01e0 5000 1800 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 The table on my Kingston-provided adatper, which reads correctly with v92, is identical. 2646 0001 0000 0000 0000 0000 0000 0000 006b 0104 c000 3bf0 0200 1e00 0000 0800 8d01 0003 0000 7800 01e0 5000 1800 0000 0000 0000 0000 0000 0000 0000 0000 0000 Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 From j.stifter@medres.ch Fri, 19 May 2000 08:47:20 +0200 Date: Fri, 19 May 2000 08:47:20 +0200 From: Jan Stifter j.stifter@medres.ch Subject: [tulip] how do i unsubscribe sorry for this stupid question, but it seems that the unsubscribe doesn't work: i sent a message to linux-tulip-request@beowulf.org with unsubscribe in the body: On 19 May 2000 06:42:22 -0000, MAILER-DAEMON@caramel.medres.ch wrote: >Hi. This is the qmail-send program at caramel.medres.ch. >I'm afraid I wasn't able to deliver your message to the following addresses. >This is a permanent error; I've given up. Sorry it didn't work out. > >: >209.220.232.76 does not like recipient. >Remote host said: 550 ... User unknown >Giving up on 209.220.232.76. > >--- Below this line is a copy of the message. > >Return-Path: >Received: (qmail 6807 invoked by uid 1004); 19 May 2000 06:42:21 -0000 >Received: from j.stifter@medres.ch by caramel with scan4virus-0.19 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.297149 secs); 19/05/2000 08:42:21 >Received: from unknown (HELO poseidon.medres.ch) (212.254.210.230) > by caramel.medres.ch with SMTP; 19 May 2000 06:42:21 -0000 >From: Jan Stifter >To: linux-tulip-request@beowulf.org >Subject: unsubscribe >Date: Fri, 19 May 2000 08:43:57 +0200 >Organization: Medres AG >Reply-To: j.stifter@medres.ch >Message-ID: <4lo9is8hcgpq4iigmqh0qo8kkmcalg0d1f@4ax.com> >X-Mailer: Forte Agent 1.8/32.548 >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: quoted-printable > >unsubscribe > so either point me, where i can unsubscribe myself or unsubscribe me manually. thanks jan From j.stifter@medres.ch Fri, 19 May 2000 09:11:17 +0200 Date: Fri, 19 May 2000 09:11:17 +0200 From: Jan Stifter j.stifter@medres.ch Subject: [tulip] how do i unsubscribe sorry, i found it on the new web-interface. please ignore my message. jan From homer@lightlink.com Fri, 19 May 2000 10:57:05 -0400 (EDT) Date: Fri, 19 May 2000 10:57:05 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] Re: Digital Tulip Design On Fri, 19 May 2000, Donald Becker wrote: > On Mon, 8 May 2000, Homer Wilson Smith wrote: > > > > I was not able to get v92g to run in linux 2.0.36. > > > You don't have 'pci-scan.o' loaded. > > This worked beautifully, still no FD on 21143 Kingstons. > > Using insmod tulip options=x AFTER pci_scan is loaded, > > the only options that tulip diag reports as full duplex are > > 4,5,8,10,26 and 27. > > Hmmm, did you try #14? > This should set MII- 100baseTx-FD We need full dup in 10baseT-FD mode. The 100 base T has always worked fine. > > > Perhaps it is a problem with Cisco 1900 Switches in Full Dup mode? > > Ciscos switches frequently have broken autonegotiation. > > > May 10 19:25:46 jane kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker > > May 10 19:25:46 jane kernel: http://www.scyld.com/network/tulip.html > > May 10 19:25:46 jane kernel: eth0: Digital DS21143 Tulip rev 65 at 0x2820000, 00:40:F0:4C:E6:A9, IRQ 11. > > May 10 19:25:46 jane kernel: eth0: EEPROM default media type Autosense. > > May 10 19:25:46 jane kernel: eth0: Index #0 - Media MII 100baseTx (#13) > > described by a 21140 non-MII (0) block. > > Huh? That's not right. It should be just "MII transceiver". > I have what I believe is an identical board that has no problem with v0.92 > > > May 10 19:25:46 jane kernel: eth0: MII transceiver #1 config 3100 status > > 782d advertising 03e0. > > > > Media MII, block type 3, length 13. > > MII interface PHY 0 (media type 11). > > That looks normal. > > > 2646 0001 0000 0000 0000 0000 0000 0300 > > 10a6 0104 c000 4cf0 a9e6 1e00 0000 0800 > > 8d01 0003 0000 7800 01e0 5000 1800 0000 > > 0000 0000 0000 0000 0000 0000 0000 0000 > > The table on my Kingston-provided adatper, which reads correctly with v92, > is identical. > 2646 0001 0000 0000 0000 0000 0000 0000 > 006b 0104 c000 3bf0 0200 1e00 0000 0800 > 8d01 0003 0000 7800 01e0 5000 1800 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > > > Donald Becker becker@scyld.com > Scyld Computing Corporation > 410 Severn Ave. Suite 210 > Annapolis MD 21403 > > From x@xman.org Fri, 19 May 2000 18:52:25 -0700 Date: Fri, 19 May 2000 18:52:25 -0700 From: Christopher Smith x@xman.org Subject: [tulip] Re: Linksys Network Card not working On Wed, May 17, 2000 at 09:17:08PM -0400, Donald Becker wrote: > On Wed, 17 May 2000, Poly wrote: > > In /var/log/messages, I found the following suspicious lines: > > The PCI BIOS has not enabled the device at 0/96 > > updating PCI Command 0083 to 0087 > > tulip.c :v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov > > eth0: Lite-on PNIC-II rev 37 at 0x1400, 00:A0:CC > > :37:95:B8, IRQ 0 > > IRQ 0 > Read > http://www.scyld.com/expert/irq-conflict.html After you fix that you will potentially find problems with the card's autonegotiation if you are using a switch. This can be corrected either by upgrading to Donald's latest driver, upgrading to the latest devel kernel, or applying this attached patch against the driver in the 2.2.x kernel. I recommend only going with the patch if you actually experience the problem, as I wrote it myself and my knowledge of the tulip driver, tulip chip, and network driver programming is miniscule compared to the collective efforts that went into the driver in the first place, so there's a decent chance the patch causes problems elsewhere (although I haven't had any problems). --Chris patch: --- donald/tulip.c Tue Apr 11 21:03:51 2000 +++ tulip/tulip.c Tue Apr 11 21:07:17 2000 @@ -18,7 +18,7 @@ */ #define SMP_CHECK -static const char version[] = "tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov\n"; +static const char version[] = "tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov\nModified (ver.5) by Christopher Smith (x@xman.org) to work with Linksys LNE100TX\nPlease do not bug Donald about problems with this driver until you've tested with regular v0.91g-ppc\n"; /* A few user-configurable values. */ @@ -389,6 +389,7 @@ HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | MC_HASH_ONLY, tulip_timer }, { "Lite-On PNIC-II", 256, 0x0801fbff, HAS_MII | HAS_NWAY143 | HAS_8023X, t21142_timer }, + // HAS_MII | HAS_NWAY143 | HAS_8023X, mxic_timer }, { "ADMtek Comet", 256, 0x0001abef, MC_HASH_ONLY, comet_timer }, { "Compex 9881 PMAC", 128, 0x0001ebef, @@ -949,7 +950,6 @@ outl(tp->mtable->csr12dir | 0x100, ioaddr + CSR12); break; case DC21142: - case PNIC2: if (tp->mii_cnt || media_cap[dev->if_port] & MediaIsMII) { outl(0x82020000, ioaddr + CSR6); outl(0x0000, ioaddr + CSR13); @@ -973,7 +973,7 @@ outl(0x000711C0, ioaddr + CSR14); /* Turn on NWay. */ outl(0x00000001, ioaddr + CSR13); break; - case MX98715: case MX98725: + case MX98715: case MX98725: case PNIC2: outl(0x01a80000, ioaddr + CSR6); outl(0xFFFFFFFF, ioaddr + CSR14); outl(0x00001000, ioaddr + CSR12); @@ -1524,8 +1524,9 @@ outl(0x0000, ioaddr + CSR14); } else t21142_start_nway(dev); - } else if (tp->chip_id == PNIC2) { - t21142_start_nway(dev); + // Chris hack + // } else if (tp->chip_id == PNIC2) { + // t21142_start_nway(dev); } else if (tp->chip_id == LC82C168 && ! tp->medialock) { if (tp->mii_cnt) { dev->if_port = 11; @@ -1546,7 +1547,7 @@ dev->if_port = 0; tp->csr6 = 0x01880000 | (tp->full_duplex ? 0x0200 : 0); outl(0x0f370000 | inw(ioaddr + 0x80), ioaddr + 0x80); - } else if (tp->chip_id == MX98715 || tp->chip_id == MX98725) { + } else if (tp->chip_id == MX98715 || tp->chip_id == MX98725 || tp->chip_id == PNIC2) { /* Provided by BOLO, Macronix - 12/10/1998. */ dev->if_port = 0; tp->csr6 = 0x01a80200; From pogosyan@cita.utoronto.ca Sat, 20 May 2000 14:33:24 -0400 Date: Sat, 20 May 2000 14:33:24 -0400 From: Dmitri Pogosyan pogosyan@cita.utoronto.ca Subject: [tulip] Lynksys ver2 not yet working Hi, O'K I know it is not yet a problem, just I'm lacking understanding something in configuration, so I'd appreciate some guidance I'm running 2.2.5 kernel (remnant of RH6.0 installation) and already have one tulip card (Accton EN1207 with original DEC 21140 chip - I guess 21140 AB) in my computer. It lives happily with 89H tulip driver. Now I got Lynksys 100 TX Fast Ethernet Adaptor (ver 2) yesterday and plug it into my machine, and it does not work. Of course, you would say that I should upgrade to newer kernel/driver or use the driver supplied by Lynksys, and this will be a part of my question. But, first of all preliminaries PCI code detects the card allright (to my understanding) #cat /proc/pci Bus 0, device 10, function 0: Ethernet controller: DEC DC21140 (rev 34). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xc000 [0xc001]. Non-prefetchable 32 bit memory at 0xe1800000 [0xe1800000]. Bus 0, device 11, function 0: Ethernet controller: LiteOn Unknown device (rev 37). Vendor id=11ad. Device id=c115. Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. I/O at 0xb800 [0xb801]. Non-prefetchable 32 bit memory at 0xe1000000 [0xe1000000]. tulip-diag is also happy ( I have version v1.19 10/2/99, so fairly new in comparison with the tulip driver itself) #tulip-diagtulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21140 Tulip adapter at 0xc000. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Index #2: Found a Lite-On PNIC-II adapter at 0xb800. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000020ce. The current PNIC-II MAC address is 00:a0:cc:e3:63:83 (a000a000 e3cc8363). The current PNIC-II WOL address is 00:a0:cc:e3:63:83. Internal autonegotiation state is 'Ability detect'. 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. -------- What is wrong, is that no eth1 interface was created. Looking in /var/log/messages on boot we see the problem May 20 11:21:08 localhost kernel: tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa .gov May 20 11:21:08 localhost kernel: eth0: Digital DS21140 Tulip at 0xc000, 00 00 e 8 4e 5f 09, IRQ 9. May 20 11:21:08 localhost kernel: eth0: MII transceiver found at MDIO address 1 , config 1000 status 782d. May 20 11:21:08 localhost kernel: PCI latency timer (CFLT) is 0x20, PCI comma nd is 0017. May 20 11:21:08 localhost kernel: Unknown Tulip-style PCI ethernet chip type 11a d c115 detected: not configured. ----------------- So is this just a problem of old tulip driver, or I don't load the module properly (I tried to load manually with no effect - eth1 does not appear ) ? I read somewhere that there can be the problem with 2 tulip cards that the second is not recognized and you have to supply i/o address to modprobe option explicitly. But I cannot find the reference. Now more specific questions: I tried to compile Donalds latest 0.92 driver, which is advertised to be compilable under every recent kernel but I'm getting #gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c tulip.c tulip.c:161: pci-scan.h: No such file or directory tulip.c:162: kern_compat.h: No such file or directory I guess I'm missing some parts ? Attempt to compile tulip.c which comes on Lynksys floppy produce the whole stream of errors. Should it be possible to compile it with 2.2.5 kernel or probably just not ? Best regards, Dmitri Pogosyan From pogosyan@cita.utoronto.ca Sat, 20 May 2000 14:39:15 -0400 Date: Sat, 20 May 2000 14:39:15 -0400 From: Dmitri Pogosyan pogosyan@cita.utoronto.ca Subject: [tulip] mII-diag Playing with my tulip card (Accton EN1207 DEC21140 chip (AB ? ) ) recently I got the following with mii-diag tulip-diag is happy, giving #tulip-diag -m tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21140 Tulip adapter at 0xc000. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 1000 782d 7810 0001 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 2089 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000. but mii-diag fails #mii-diag eth0 SIOCGMIIPHY on eth0 failed: No such device # Is this how it is supposed to be with this card ? Best regards, Dmitri Pogosyan From cormierf@flashmail.com Sat, 20 May 2000 15:51:35 -0400 Date: Sat, 20 May 2000 15:51:35 -0400 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Cormier cormierf@flashmail.com Subject: [tulip] Lynksys ver2 not yet working Hi, The basic answer is that when you compile tulip.c v0.92, you also have to compile pci-scan.c that came with it. When it's done, run depmod -a to check module dependencies and then you can do modprobe tulip, or you can insert the pci-scan.o module manually before inserting the tulip.o module. At 14:33 00-05-20 -0400, you wrote: >Hi, >O'K I know it is not yet a problem, just I'm lacking understanding >something in >configuration, so I'd appreciate some guidance > >I'm running 2.2.5 kernel (remnant of RH6.0 installation) and already >have one tulip >card (Accton EN1207 with original DEC 21140 chip - I guess 21140 AB) in >my computer. >It lives happily with 89H tulip driver. > >Now I got Lynksys 100 TX Fast Ethernet Adaptor (ver 2) yesterday and >plug it >into my machine, and it does not work. Of course, you would say that >I should >upgrade to newer kernel/driver or use the driver supplied by Lynksys, >and this will be >a part of my question. But, first of all preliminaries > >PCI code detects the card allright (to my understanding) >#cat /proc/pci > > Bus 0, device 10, function 0: > Ethernet controller: DEC DC21140 (rev 34). > Medium devsel. Fast back-to-back capable. IRQ 9. Master >Capable. Latency=32. Min Gnt=20.Max Lat=40. > I/O at 0xc000 [0xc001]. > Non-prefetchable 32 bit memory at 0xe1800000 [0xe1800000]. > Bus 0, device 11, function 0: > Ethernet controller: LiteOn Unknown device (rev 37). > Vendor id=11ad. Device id=c115. > Medium devsel. Fast back-to-back capable. IRQ 11. Master >Capable. Latency=32. Min Gnt=8.Max Lat=56. > I/O at 0xb800 [0xb801]. > Non-prefetchable 32 bit memory at 0xe1000000 [0xe1000000]. > >tulip-diag is also happy ( I have version v1.19 10/2/99, so fairly new >in comparison with the tulip driver itself) > >#tulip-diagtulip-diag.c:v1.19 10/2/99 Donald Becker >(becker@cesdis.gsfc.nasa.gov) >Index #1: Found a Digital DS21140 Tulip adapter at 0xc000. > Port selection is MII, half-duplex. > Transmit started, Receive started, half-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 128. >Index #2: Found a Lite-On PNIC-II adapter at 0xb800. > Port selection is 10mpbs-serial, half-duplex. > Transmit stopped, Receive stopped, half-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Stopped'. > The transmit threshold is 72. > The NWay status register is 000020ce. > The current PNIC-II MAC address is 00:a0:cc:e3:63:83 (a000a000 >e3cc8363). > The current PNIC-II WOL address is 00:a0:cc:e3:63:83. > Internal autonegotiation state is 'Ability detect'. > 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. > >-------- >What is wrong, is that no eth1 interface was created. Looking in >/var/log/messages on boot >we see the problem > >May 20 11:21:08 localhost kernel: tulip.c:v0.89H 5/23/98 >becker@cesdis.gsfc.nasa >.gov >May 20 11:21:08 localhost kernel: eth0: Digital DS21140 Tulip at 0xc000, >00 00 e >8 4e 5f 09, IRQ 9. >May 20 11:21:08 localhost kernel: eth0: MII transceiver found at MDIO >address 1 >, config 1000 status 782d. >May 20 11:21:08 localhost kernel: PCI latency timer (CFLT) is 0x20, >PCI comma >nd is 0017. >May 20 11:21:08 localhost kernel: Unknown Tulip-style PCI ethernet chip >type 11a >d c115 detected: not configured. > >----------------- >So is this just a problem of old tulip driver, or I don't load the >module properly >(I tried to load manually with no effect - eth1 does not appear ) ? >I read somewhere that there can be the problem with 2 tulip cards that >the second >is not recognized and you have to supply i/o address to modprobe option >explicitly. >But I cannot find the reference. > >Now more specific questions: I tried to compile Donalds latest 0.92 >driver, which is advertised >to be compilable under every recent kernel but I'm getting >#gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c tulip.c >tulip.c:161: pci-scan.h: No such file or directory >tulip.c:162: kern_compat.h: No such file or directory > >I guess I'm missing some parts ? > >Attempt to compile tulip.c which comes on Lynksys floppy produce the >whole stream of errors. >Should it be possible to compile it with 2.2.5 kernel or probably just >not ? > > Best regards, Dmitri Pogosyan > > > >_______________________________________________ >tulip mailing list >tulip@scyld.com >http://www.scyld.com/mailman/listinfo/tulip Fr�d�ric Cormier cormierf@flashmail.com Fr�d�ric Cormier, alias Derf derf@citeweb.net ICQ:4735399 ------------------------------------------------------ Quand je vois une grande personne sur une bicyclette, j'ai confiance dans l'esp�ce humaine. H.G. Wells ------------------------------------------------------ http://derf.citeweb.net/ From pogosyan@cita.utoronto.ca Sat, 20 May 2000 16:29:24 -0400 Date: Sat, 20 May 2000 16:29:24 -0400 From: Dmitri Pogosyan pogosyan@cita.utoronto.ca Subject: [tulip] Lynksys ver2 not yet working Thanks for your answer ! The key word was 'comes with the driver'. I actually copied the link, which gave me only tulip.c Now I looked into ftp archive where tulip.c came from, and sure enough there are the necessary files there. Now the probem is - pci-scan.c does not compile producing lots of error, including basic things like /usr/include/linux/msdos_fs_sb.h:10: parse error before `uid_t' /usr/include/linux/msdos_fs_sb.h:10: warning: no semicolon at end of struct or union etc. (this is just an example). It is the same type of erros I got while trying to compile tulip.c which came with Linksys card. Which is encouraging, meaning that something is wrong with my kernel-dependent compilation set-up. I'm using gcc-2.95.2-3 - any know problems with this compiler ? Dmitri Pogosyan From pogosyan@cita.utoronto.ca Sat, 20 May 2000 19:33:24 -0400 Date: Sat, 20 May 2000 19:33:24 -0400 From: Dmitri Pogosyan pogosyan@cita.utoronto.ca Subject: [tulip] Lynksys ver2 is working now All right, switching to egcs solved compilation problems with latest tulip driver and pci-scan.c Now if only I can make the card work at 100Mbs connection with my notebook , running Windows 98, which has 3com 10/100 Mps adapter built in. I'm using recent .92 driver from Donald. Card seems to negotiate 100baseT-FD connection first, but at this state no pings pass through (activity light is flashing when I send a ping from notebook to the card). Then 'Transmit timed out' and the card switched to 10baseT and connection worked. from /var/log/messages May 20 18:49:22 localhost kernel: eth1: N-Way autonegotiation status 000000c8, 100baseTx-FDX. May 20 18:49:22 localhost kernel: eth1: Using NWay-set 100baseTx-FDX media, csr12 000000c8. May 20 18:50:22 localhost kernel: eth1: N-Way autonegotiation status 000000c8, 100baseTx-FDX. May 20 18:50:22 localhost kernel: eth1: Using NWay-set 100baseTx-FDX media, csr12 000000c8. May 20 18:50:33 localhost kernel: eth1: Transmit timed out, status e4000000, CSR12 000000c8, resetting... May 20 18:51:22 localhost kernel: eth1: N-Way autonegotiation status 000000c8, 10baseT. May 20 18:51:22 localhost kernel: eth1: Using NWay-set 10baseT media, csr12 000000c8. Well, probably I should check Linksys drivers as well. Thanks for your help, Dmitri Pogosyan From rcm@bcnartdirecte.com Sun, 21 May 2000 13:05:11 +0200 Date: Sun, 21 May 2000 13:05:11 +0200 From: Rafael Cordones Marcos rcm@bcnartdirecte.com Subject: [tulip] IRQ Confict? Hi, I have a Xircom RBEM56G-100 which is supposed to work as a DEC 21143 clone. But it does not work well on my system with 2.2.14 kernel and pcmcia-cs-3.1.14 package. -------------------------------------------------------------------- May 21 12:48:34 moebius kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov (modified by danilo @cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) May 21 12:48:34 moebius kernel: eth0: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at 0x200, 0 0:10:A4:FA:92:69, IRQ 9. May 21 12:48:34 moebius kernel: eth0: MII transceiver #0 config 3100 status 7809 advertising 01e1. May 21 12:48:34 moebius kernel: serial_attach(bus 32, fn 1) May 21 12:48:34 moebius kernel: tty02 at 0x0280 (irq = 9) is a 16550A May 21 12:48:34 moebius cardmgr[141]: executing: './network start eth0' May 21 12:48:34 moebius kernel: eth0: tulip_open() irq 9. May 21 12:48:34 moebius cardmgr[141]: executing: './serial start ttyS2' May 21 12:50:30 moebius kernel: eth0: Transmit error, Tx status 7fff8800. May 21 12:50:31 moebius kernel: eth0: Transmit error, Tx status 7fff8800. May 21 12:50:32 moebius kernel: eth0: Transmit error, Tx status 7fff8800. -------------------------------------------------------------------- The thing is I did a cat /proc/pci and got the following: -------------------------------------------------------------------- PCI devices found: Bus 32, device 0, function 0: Ethernet controller: Unknown vendor Unknown device (rev 3). Vendor id=115d. Device id=3. Medium devsel. IRQ 9. I/O at 0x200 [0x201]. Non-prefetchable 32 bit memory at 0x60013000 [0x60013000]. Non-prefetchable 32 bit memory at 0x60012000 [0x60012000]. Bus 32, device 0, function 1: Serial controller: Unknown vendor Unknown device (rev 3). Vendor id=115d. Device id=103. Medium devsel. IRQ 9. I/O at 0x280 [0x281]. Non-prefetchable 32 bit memory at 0x60011000 [0x60011000]. Non-prefetchable 32 bit memory at 0x60010000 [0x60010000]. Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (rev 3). Medium devsel. Master Capable. Latency=64. Prefetchable 32 bit memory at 0x12000000 [0x12000008]. Bus 0, device 1, function 0: PCI bridge: Intel 440BX - 82443BX AGP (rev 3). Medium devsel. Master Capable. Latency=128. Min Gnt=140. Bus 0, device 4, function 0: Multimedia audio controller: Unknown vendor Unknown device (rev 0). Vendor id=125d. Device id=1968. Medium devsel. Fast back-to-back capable. IRQ 5. Master Capable. Latency=64. Min Gnt=2.Max Lat=24. I/O at 0xf800 [0xf801]. Bus 0, device 7, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. I/O at 0xfcd0 [0xfcd1]. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=64. I/O at 0xfce0 [0xfce1]. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 2). Medium devsel. Fast back-to-back capable. Bus 0, device 10, function 0: CardBus bridge: Texas Instruments PCI1250 (rev 2). Medium devsel. IRQ 9. Master Capable. Latency=168. Max Lat=7. Bus 0, device 10, function 1: CardBus bridge: Texas Instruments PCI1250 (rev 2). Medium devsel. IRQ 9. Master Capable. Latency=168. Min Gnt=192.Max Lat=7. Bus 1, device 0, function 0: VGA compatible controller: ATI Unknown device (rev 220). Vendor id=1002. Device id=4c42. Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=66. Min Gnt=8. Non-prefetchable 32 bit memory at 0xfd000000 [0xfd000000]. I/O at 0xe800 [0xe801]. Non-prefetchable 32 bit memory at 0xfecfe000 [0xfecfe000]. -------------------------------------------------------------------- As you can see at the begining I have the Xircom card (which is a ethernet+modem card). It has IRQ9 assigned as well as the CardBus bridge. But as can be seen at the end... the VGA Card has the *same* IRQ 9 assigned!! Is this correct? By the way, where can I find the source code of "tulip.c:v0.91g-ppc 7/16/99"?? Thanks for your time. Rafa C. Marcos -- Linux! The Choice of a GNU Generation! -> http://www.debian.org From rcm@bcnartdirecte.com Sun, 21 May 2000 18:24:16 +0200 Date: Sun, 21 May 2000 18:24:16 +0200 From: Rafael Cordones Marcos rcm@bcnartdirecte.com Subject: [tulip] netdriver-2.0 doesn't compile Hi, I have been trying to get the dirvers in the netdriver-2.0 package to compile but first I get: --------------------------------------------------------------------- gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I/usr/src/linux/include -c -o pci-skeleton.o pci-skeleton.c pci-skeleton.c:89: linux/modversions.h: No existe el fichero o el directorio In file included from pci-skeleton.c:111: kern_compat.h:38: linux/modversions.h: No existe el fichero o el directorio make: *** [pci-skeleton.o] Error 1 --------------------------------------------------------------------- "No existe el fichero o el directorio" means "File or directory does not exist". If I remove all reference to modversions.h in the c files I would get an awfully long list of errors. I am using "gcc version 2.95.2 20000313 (Debian GNU/Linux)", kernel 2.2.14 and pcmcia-cs-3.1.14. Any help would be appreciated. Thanks. Rafa -- Linux! The Choice of a GNU Generation! -> http://www.debian.org From pogosyan@cita.utoronto.ca Sun, 21 May 2000 13:24:10 -0400 Date: Sun, 21 May 2000 13:24:10 -0400 From: Dmitri Pogosyan pogosyan@cita.utoronto.ca Subject: [tulip] Linksys ver2 is working - conclusion As a conclusion: I switched to tulip.c supplied by Linksys and with this driver my Linksys 100 TX ver 2 card works fine in 100TX-Full Duplex mode, connected via crossover cable to Windows98 notebook. On contrary, 0.92 driver fails to connected at 100 Mbs connection (although it tries for some time but gets transmit timeout). Seems to be the same problem with autonegotiation of Linksys cards as was heavily discussed on this mailing list in March. Although now it is not a connection to a switch, but a direct crossover connection to another machine. Dmitri Pogosyan PS As a remark: gcc-2.95.2 failed to compile the drivers From jason@topic.com.au Mon, 22 May 2000 07:35:53 +1000 Date: Mon, 22 May 2000 07:35:53 +1000 From: Jason Thomas jason@topic.com.au Subject: [tulip] netdriver-2.0 doesn't compile --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline you need kernel headers with modules support, modversions.h is created when you compile your kernel with modules support. Rafael Cordones Marcos [rcm@bcnartdirecte.com] wrote: > Hi, > > I have been trying to get the dirvers in the netdriver-2.0 package to > compile but first I get: > > --------------------------------------------------------------------- > gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I/usr/src/linux/include -c -o pci-skeleton.o pci-skeleton.c > pci-skeleton.c:89: linux/modversions.h: No existe el fichero o el directorio > In file included from pci-skeleton.c:111: > kern_compat.h:38: linux/modversions.h: No existe el fichero o el directorio > make: *** [pci-skeleton.o] Error 1 > --------------------------------------------------------------------- > "No existe el fichero o el directorio" means "File or directory does not > exist". > > If I remove all reference to modversions.h in the c files I would get an > awfully long list of errors. > > I am using "gcc version 2.95.2 20000313 (Debian GNU/Linux)", > kernel 2.2.14 and pcmcia-cs-3.1.14. > > Any help would be appreciated. Thanks. > > Rafa > > -- > Linux! The Choice of a GNU Generation! -> http://www.debian.org > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip -- Jason Thomas System Administrator - UID 0 Phone: +61 2 6257 7111 tSA Consulting Group Pty. Ltd. Fax: +61 2 6257 7311 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: 49s9BIj2vBChB58OP9A4zEEKyzrOVygh Comment: Ha Ha iQA/AwUBOShWuO3GMESSUoi+EQIpRACeLD2wog5qZLmTE09mJJnUMyFnp2wAoJlE xw5/kWZ61DjDJOnEKIcUsaX1 =7cyv -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From steven.fosdick@btinternet.com Mon, 22 May 2000 00:22:05 +0100 Date: Mon, 22 May 2000 00:22:05 +0100 From: Steven Fosdick steven.fosdick@btinternet.com Subject: [tulip] Re: Problems with the Netgear FA310TX - Reset Chip Hello Donald (and list), I was wondering if you had any further thoughts on the TX lockup problem I am having with the FA310TX card in 10MbitHD mode that I mentioned in my e-mail to the list on 4th May, with further information on 6th May? When the driver detects a TX timeout it stops and starts the receiver, but in my case that doesn't seem to get the transmitter working again - it remains "waiting for TX to finish". Using ifconfig to take the interface down, then bring it up again does get things going again. Assuming the has the effect of calling tulip_close followed by tulip_open I would guess that it is resetting the chip that actually does the trick, so I then thought that it may be possible to work around this problem by resetting the chip when we detect a TX timeout. That brings me on to a couple of other questions: 1. In the tulip_open function it says that we must wait 50 PCI cycles between asserting the reset bit and clearing it again, but the only function to be called between these two is request_interrupt and I am not clear as to how this waits the appropriate time. 2. Having reset the chip, how much of the work in tulip_open has to be re-done? I would guess at everything except the request_interrupt and tulip_init_ring, but I would like your guidance on that one. With this information I would hope to test a modified version of the driver that resets the chip upon detecting the timeout. I am quite happy to try making the necessary modifications and let you know the outcome. Unless, of course, you have any other ideas. Steve Fosdick. From steven.fosdick@btinternet.com Mon, 22 May 2000 09:38:50 +0100 Date: Mon, 22 May 2000 09:38:50 +0100 From: Steven Fosdick steven.fosdick@btinternet.com Subject: [tulip] Re: Problems with the Netgear FA310TX - Reset Chip On Mon, May 22, 2000 at 12:22:05AM +0100, I wrote: > When the driver detects a TX timeout it stops and starts the receiver, but I should have said: > When the driver detects a TX timeout it stops and starts the TRANSMITTER, Steve From thomas@cs.wisc.edu Mon, 22 May 2000 10:26:37 -0500 Date: Mon, 22 May 2000 10:26:37 -0500 From: David Thompson thomas@cs.wisc.edu Subject: [tulip] Re: Kingston Yes, we're seeing some problems with a similar configuration (kingston 21143, tulip v0.91g, to a cisco switch). Our kernel is much newer, 2.2.12. In the testing I've done, that cards start out negotiating correctly (full dup), but then randomly drop back to half dup. This sucks. I also tried to force full duplex everywhere. The options= parameter doesn't seem to work as documented on these cards. Anyone else have any experience with this? -- Dave Thompson Associate Researcher Department of Computer Science University of Wisconsin-Madison http://www.cs.wisc.edu/~thomas 1210 West Dayton Street Phone: (608)-262-1017 Madison, WI 53706-1685 Fax: (608)-262-6626 -- Homer Wilson Smith wrote: > > I am unable to get Kingston KNE100TX 21143's to go into >Full Dup with Cisco Switches. > > With the SMC cards work right with Linux 2.0.36 and v91g? > > Thanks Homer > >------------------------------------------------------------------------ >Homer Wilson Smith Clear Air, Clear Water, Art Matrix - Lightlink >(607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY >homer@lightlink.com Is that too much to ask? http://www.lightlink.com > >------------------------------------------------------------------- From Layla3000@aol.com Mon, 22 May 2000 12:44:34 EDT Date: Mon, 22 May 2000 12:44:34 EDT From: Layla3000@aol.com Layla3000@aol.com Subject: [tulip] Help! Hello; I hope that some how that you can help me. I am searching for the web site or ANY information about Liteon drivers. I need to update my driver which is Liteon CD Rom LTN 301. This driver does not support multi-session soft ware and what I am using it for mainly is to load pictures from a Kodak Picture CD. If you have any information that could help me, I would really appreciate it. I own a Packard Bell computer and as you might or might not know they are out of business so I can not call upon them for help. Thank-you for taking a moment to read this e-mail. Jeanine Coyne(Layla3000@aol.com) :) From homer@lightlink.com Mon, 22 May 2000 13:29:09 -0400 (EDT) Date: Mon, 22 May 2000 13:29:09 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] Re: Kingston > Yes, we're seeing some problems with a similar configuration (kingston > 21143, tulip v0.91g, to a cisco switch). Our kernel is much newer, > 2.2.12. In the testing I've done, that cards start out negotiating > correctly (full dup), but then randomly drop back to half dup. I have pretty much given up with the 21143 chips, even v92 doesn't work. If someone knows another card that will do 10baseT Full Dup properly with a Cisco 1900 Switch I would love to know. Homer From cbrown@denalics.net Mon, 22 May 2000 12:12:27 -0900 (HADT) Date: Mon, 22 May 2000 12:12:27 -0900 (HADT) From: Christopher E. Brown cbrown@denalics.net Subject: [tulip] Re: Kingston On Mon, 22 May 2000, David Thompson wrote: > > Yes, we're seeing some problems with a similar configuration (kingston > 21143, tulip v0.91g, to a cisco switch). Our kernel is much newer, > 2.2.12. In the testing I've done, that cards start out negotiating > correctly (full dup), but then randomly drop back to half dup. > > This sucks. > > I also tried to force full duplex everywhere. The options= parameter > doesn't seem to work as documented on these cards. > > Anyone else have any experience with this? What Kingston card? I have had zero problems with the KNE100TX units. The later ones (21143 based) require a .91 driver, but thats it. I have > 100 used (20 somthing are 21143), and about 15 of the 21143 units are talking to cisco switches. --- As folks might have suspected, not much survives except roaches, and they don't carry large enough packets fast enough... --About the Internet and nuclear war. From homer@lightlink.com Mon, 22 May 2000 19:07:00 -0400 (EDT) Date: Mon, 22 May 2000 19:07:00 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] Re: Kingston > What Kingston card? I have had zero problems with the > KNE100TX units. The later ones (21143 based) require a .91 driver, > but thats it. I have > 100 used (20 somthing are 21143), and about 15 > of the 21143 units are talking to cisco switches. I am using KNE100TX with 21143 connected to cisco 1900, 10baseT forced full dup. The card won't auto negotiate, but can be 'forced' into various Fd modes through the options=command. Most of the FD modes don't work at all, some do work, but statistics on the Ciscos show lots of runt frames and very slow throughput, the usual signs of the card being in half duplex and the Cisco being in full. This behavior is replicateable with the 21140 by actually putting them in half duplex while the cisco is in full dup. The 21140's work properly providing 1000Kbyte/sec throughput between two linux boxes in FD mode options=16. The Full dup green light never turns on in either card, but we are very happy with the performance of the 21140's. Alsa they are no longer avialable. If I am doing something stupid here, I would dearly love to know because we are very dedicated to the Kingston 2114x's Homer > > --- > As folks might have suspected, not much survives except roaches, > and they don't carry large enough packets fast enough... > --About the Internet and nuclear war. > > From jason@topic.com.au Tue, 23 May 2000 09:54:26 +1000 Date: Tue, 23 May 2000 09:54:26 +1000 From: Jason Thomas jason@topic.com.au Subject: [tulip] Re: Kingston --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Is the switch a Catalyst 1900, if so, it only autonegotiates duplex operation on 100BaseTx ports. http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/1928v9x/19icg9x/19icintr.htm Homer Wilson Smith [homer@lightlink.com] wrote: > > What Kingston card? I have had zero problems with the > > KNE100TX units. The later ones (21143 based) require a .91 driver, > > but thats it. I have > 100 used (20 somthing are 21143), and about 15 > > of the 21143 units are talking to cisco switches. > > I am using KNE100TX with 21143 connected to cisco 1900, > 10baseT forced full dup. The card won't auto negotiate, but > can be 'forced' into various Fd modes through the options=command. > > Most of the FD modes don't work at all, some do work, but statistics > on the Ciscos show lots of runt frames and very slow throughput, the usual > signs of the card being in half duplex and the Cisco being in full. > > This behavior is replicateable with the 21140 by actually > putting them in half duplex while the cisco is in full dup. > > The 21140's work properly providing 1000Kbyte/sec throughput > between two linux boxes in FD mode options=16. > > The Full dup green light never turns on in either card, > but we are very happy with the performance of the 21140's. > Alsa they are no longer avialable. > > If I am doing something stupid here, I would dearly love > to know because we are very dedicated to the Kingston 2114x's > > Homer > > > > --- > > As folks might have suspected, not much survives except roaches, > > and they don't carry large enough packets fast enough... > > --About the Internet and nuclear war. > > > > > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip -- Jason Thomas System Administrator - UID 0 Phone: +61 2 6257 7111 tSA Consulting Group Pty. Ltd. Fax: +61 2 6257 7311 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: KuYcPdTuXvTnMerCCVLbq1J96QwQoNNf Comment: Ha Ha iQA/AwUBOSnIsu3GMESSUoi+EQJuvwCggPN+idMXmdAOF0UH6wPgVlDCY+IAoNtg is/iAH/dFcmZecYtFDDraPMj =6Ysj -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From cbrown@denalics.net Mon, 22 May 2000 15:40:24 -0900 (HADT) Date: Mon, 22 May 2000 15:40:24 -0900 (HADT) From: Christopher E. Brown cbrown@denalics.net Subject: [tulip] Re: Kingston On Mon, 22 May 2000, Homer Wilson Smith wrote: > > What Kingston card? I have had zero problems with the > > KNE100TX units. The later ones (21143 based) require a .91 driver, > > but thats it. I have > 100 used (20 somthing are 21143), and about 15 > > of the 21143 units are talking to cisco switches. > > I am using KNE100TX with 21143 connected to cisco 1900, > 10baseT forced full dup. The card won't auto negotiate, but > can be 'forced' into various Fd modes through the options=command. > > Most of the FD modes don't work at all, some do work, but statistics > on the Ciscos show lots of runt frames and very slow throughput, the usual > signs of the card being in half duplex and the Cisco being in full. > > This behavior is replicateable with the 21140 by actually > putting them in half duplex while the cisco is in full dup. > > The 21140's work properly providing 1000Kbyte/sec throughput > between two linux boxes in FD mode options=16. > > The Full dup green light never turns on in either card, > but we are very happy with the performance of the 21140's. > Alsa they are no longer avialable. > > If I am doing something stupid here, I would dearly love > to know because we are very dedicated to the Kingston 2114x's > > Homer Am very confused here, I have been using the KNE100TX units, 1 - 4 per box for some time. When the 21143 units started arriveing it was fun, but as soon as I switched from 89h everything was happy again. I checked, the 15 21143 KNE100TX cards are talking to Catalyst 2900 series units. All drop straight into 100FD, and more than a few hold 80Mbit+ each way during office hrs (Linux based filtering firewalls, and MASQ boxes). --- As folks might have suspected, not much survives except roaches, and they don't carry large enough packets fast enough... --About the Internet and nuclear war. From homer@lightlink.com Tue, 23 May 2000 00:44:59 -0400 (EDT) Date: Tue, 23 May 2000 00:44:59 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] Re: Kingston Thanks, this is not a problem in autonegotiation, in 10baseT mode, the switch can be forced into Full Dup mode. It works flawlessly with the 21140 options=16, but the 21143 doesn't work at all. Its a real problem. ------------------------------------------------------------------------ Homer Wilson Smith Clear Air, Clear Water, Art Matrix - Lightlink (607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY homer@lightlink.com Is that too much to ask? http://www.lightlink.com On Tue, 23 May 2000, Jason Thomas wrote: > Is the switch a Catalyst 1900, if so, it only autonegotiates duplex > operation on 100BaseTx ports. > > http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/1928v9x/19icg9x/19icintr.htm > > Homer Wilson Smith [homer@lightlink.com] wrote: > > > What Kingston card? I have had zero problems with the > > > KNE100TX units. The later ones (21143 based) require a .91 driver, > > > but thats it. I have > 100 used (20 somthing are 21143), and about 15 > > > of the 21143 units are talking to cisco switches. > > > > I am using KNE100TX with 21143 connected to cisco 1900, > > 10baseT forced full dup. The card won't auto negotiate, but > > can be 'forced' into various Fd modes through the options=command. > > > > Most of the FD modes don't work at all, some do work, but statistics > > on the Ciscos show lots of runt frames and very slow throughput, the usual > > signs of the card being in half duplex and the Cisco being in full. > > > > This behavior is replicateable with the 21140 by actually > > putting them in half duplex while the cisco is in full dup. > > > > The 21140's work properly providing 1000Kbyte/sec throughput > > between two linux boxes in FD mode options=16. > > > > The Full dup green light never turns on in either card, > > but we are very happy with the performance of the 21140's. > > Alsa they are no longer avialable. > > > > If I am doing something stupid here, I would dearly love > > to know because we are very dedicated to the Kingston 2114x's > > > > Homer > > > > > > --- > > > As folks might have suspected, not much survives except roaches, > > > and they don't carry large enough packets fast enough... > > > --About the Internet and nuclear war. > > > > > > > > > > > > _______________________________________________ > > tulip mailing list > > tulip@scyld.com > > http://www.scyld.com/mailman/listinfo/tulip > > -- > Jason Thomas > System Administrator - UID 0 Phone: +61 2 6257 7111 > tSA Consulting Group Pty. Ltd. Fax: +61 2 6257 7311 > 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ > From homer@lightlink.com Tue, 23 May 2000 00:46:34 -0400 (EDT) Date: Tue, 23 May 2000 00:46:34 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] Re: Kingston > Am very confused here, I have been using the KNE100TX units, 1 > - 4 per box for some time. When the 21143 units started arriveing it > was fun, but as soon as I switched from 89h everything was happy > again. I checked, the 15 21143 KNE100TX cards are talking to Catalyst > 2900 series units. All drop straight into 100FD, and more than a few > hold 80Mbit+ each way during office hrs (Linux based filtering > firewalls, and MASQ boxes). 2900 series is 100baseT , we are using 1900 which has 10baseT ports. The 21143's work fine in 100baseT mode. Homer > > > --- > As folks might have suspected, not much survives except roaches, > and they don't carry large enough packets fast enough... > --About the Internet and nuclear war. > > From undefined@engineer.com Tue, 23 May 2000 01:08:32 +0000 Date: Tue, 23 May 2000 01:08:32 +0000 From: undefined@engineer.com undefined@engineer.com Subject: [tulip] ton o' errors with netgear NIC Mr. Becker and other mailing-list participants, In my home I have 2 computers, each with a Netgear card, connected merely by a crossover cable. Under light network-traffic loads running interactive network applications (telnet, ssh, linuxconf, swat for samba) between the two computers, the two computers are happy. But when transfering (ftp, scp) a file greater than (approx.) 100 KB between the computers, one computer complains loudly of errors. Large files transfered in one specific direction actually slow to a patheticcrawl after the first 600 KB (see trouble-shooting below for a more detailed description). So it's not just errors, but the problem causes severe network slow-downs. I have read the mailing-list archives as far back as Jan '99 and did not see a problem posted similar to mine, though after the first 3 hours of reading the problems all seem the same. I have tried to include all information that I saw included and saw requested in previous postings from the archive. I have also included general computer hardware and configuration information. Below is all information I could think of extracting from both computers relevant to this problem, and following that is a description of my trouble-shooting to date. NOTE: I simply refer to the two computers as "tulip" and "ne2k" as those are generic descriptions of the installed NICs and the easiest way to distinguish between the two computers on a mailing-list specifically concerning NIC drivers. tulip: Netgear FA310TX PCI Red Hat 6.1 kernel 2.2.12-20 tulip.c v0.89H 5/23/98 and upgraded to v0.92 4/17/2000 circa '98-'99 PII-450 (440BX chipset) ne2k: Netgear EA201c Red Hat 6.1 kernel 2.2.12-20 ne.c v1.10 9/23/94 circa '94 486 (ISA & VLB only) connected by cat5 crossover cable EDITORIAL NOTE: Hardware addresses withheld due to privacy concerns. If the hardware addresses are really necessary for trouble-shooting, then please request that I mail them directly to your email address, and not to a public forum. --- dmesg on tulip --- tulip.c:v0.92 4/17/2000 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: Lite-On 82c168 PNIC rev 32 at 0xc40f1000, **:**:**:**:**:**, IRQ 5. eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. --- /var/log/messages on tulip --- no errors or any references --- eth0 in /proc/net/dev on tulip --- Receive bytes packets errs drop fifo frame compressed multicast 1008022 1427 523 0 0 1046 0 0 Transmit bytes packets errs drop fifo colls carrier compressed 1662749 1855 307 0 0 276 307 0 --- ifconfig eth0 on tulip --- Link encap:Ethernet HWaddr **:**:**:**:**:** inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1427 errors:523 dropped:0 overruns:0 frame:1046 TX packets:1855 errors:307 dropped:0 overruns:0 carrier:307 collisions:276 txqueuelen:100 Interrupt:5 Base address:0x1000 --- mii-diag on tulip --- mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Basic registers of MII PHY #1: 3000 782d 0040 6212 01e1 0021 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner is generating 10baseT link beat (no autonegotiation). --- tulip-diag on tulip --- tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xd400. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 3000 782d 0040 6212 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 5000 0000 0000 0000 0000 0000 0300 0000 003c 8006 0f00 ff00 002c 4000 0080 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. No specific information is known about this transceiver type. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. --- dmesg on ne2k --- ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov) NE*000 ethercard probe at 0x300: ** ** ** ** ** ** eth0: NE2000 found at 0x300, using IRQ 10. --- /var/log/messages on ne2k --- no errors or any references --- eth0 in /proc/net/dev on ne2k --- Receive bytes packets errs drop fifo frame compressed multicast 1667226 1940 0 0 0 230 0 1 Transmit bytes packets errs drop fifo colls carrier compressed 1562737 2043 0 0 0 0 0 0 --- ifconfig eth0 on ne2k --- Link encap:Ethernet HWaddr **:**:**:**:**:** inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1933 errors:0 dropped:0 overruns:0 frame:230 TX packets:2036 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x300 --- ne2k-diag on ne2k --- ne2k-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) Checking the ethercard at 0x300. Receive alignment error counter (0x30d) is ff Passed initial NE2000 probe, value 00. Station Address PROM 0: ** ** ** ** ** ** ** ** ** ** ** ** 00 00 00 00 Station Address PROM 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 57 57 57 57 NE2000 found at 0x300, using start page 0x40 and end page 0x80. The current MAC stations address is **:**:**:**:**:**. 8390 page 0: 20 ff ff 7a 42 00 ff 00 20 00 7b ff 21 00 00 00. 8390 page 1: 60 ** ** ** ** ** ** 7b 00 00 00 80 00 ff 00 00. 8390 page 2: 00 ff 49 ff 49 ff 49 ff 49 ff 49 ff 49 ff 49 ff. 8390 page 3: e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff. --- What have I tried so far? I noticed that the tulip was the one screaming about errors, so I assume (very possibly incorectly) that the problem lies with it. The network slowdown is also greatest when transfering from tulip to ne2k. (Though that doesn't really suggest anything as the problem could be ne2k RX and not necessarily tulip TX.) That's why I'm posting to this tulip mailing-list, instead of the ne2k mailing-list (if one even exists). I've also focused most of my trouble-shooting on the tulip. Since all the errors were on the tulip, I first thought maybe it was the tulip driver. So I upgraded to v0.92 from netdriver-2.0-2.src.rpm. No improvement. Tulip dual-boots between linux and win98, so I transfered (ftp) files between tulip (in both OSes) and ne2k, and based on throughput numbers win98 is quite faster, which makes me believe the problem is driver-based and not hardware-based. But I don't know of a ifconfig or /proc/net/dev equivalent in win98, so maybe the problem of massive errors still exists in win98, I just can't see the errors. I then started reading the mailing-list archives and saw a mention of bad cabling. "Duh," I thought, but I don't have a spare known-working crossover cable (nor do we have them in general use at work for me to borrow overnight) to test with. But if the problem was with the cabling wouldn't there be errors reported on both computers instead of all (TX and RX) on one end? I did flip-flop which end of the crossover cable was plugged into which computer, but all the errors continued to be reported by tulip. If this is very possibly the problem, then I'll purchase another crossover cable for testing, but I would prefer to not have to. I've checked the simple configuration stuff like IRQ, but that doesn't seem to be the problem. Both cards are recognized with no problems reported, so it makes me believe it's something else besides driver configuration, like the driver itself. Oh, I don't think it's the TCP/IP stack, as I use to have these machines connected by PLIP, and never encountered any problems (besides balancing the use of the parallel port with both PLIP and a printer). I am unable to solve the problem, and short of testing (which requires buying) a new crossover cable and new NICs, I don't know what to test or try next. I apologize if the problem/solution is obvious from the above information, and I've just happened to be blind to it. If that's the case, then I am sorry I wasted your time and bandwidth, but please still inform me of the solution (with whatever ridicule you fill necessary). Thank you in advance for your assistance. C o r e y W r i g h t mailto:undefined@pobox.com http://zeros-ones.homepage.com/Corey-Wright-public-key.html From jason@topic.com.au Tue, 23 May 2000 17:01:30 +1000 Date: Tue, 23 May 2000 17:01:30 +1000 From: Jason Thomas jason@topic.com.au Subject: [tulip] ton o' errors with netgear NIC --HB4mHL4PVvkpZAgW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline there is a newer 8390 driver available, I assume that is the chip on th ne2k card you have. its called 8390too or something maybe this can help. undefined@engineer.com [undefined@engineer.com] wrote: > Mr. Becker and other mailing-list participants, > > In my home I have 2 computers, each with a Netgear card, connected merely > by a crossover cable. Under light network-traffic loads running > interactive network applications (telnet, ssh, linuxconf, swat for samba) > between the two computers, the two computers are happy. But when > transfering (ftp, scp) a file greater than (approx.) 100 KB between the > computers, one computer complains loudly of errors. Large files transfered > in one specific direction actually slow to a patheticcrawl after the first > 600 KB (see trouble-shooting below for a more detailed description). So > it's not just errors, but the problem causes severe network slow-downs. > > I have read the mailing-list archives as far back as Jan '99 and did not > see a problem posted similar to mine, though after the first 3 hours of > reading the problems all seem the same. I have tried to include all > information that I saw included and saw requested in previous postings from > the archive. I have also included general computer hardware and > configuration information. Below is all information I could think of > extracting from both computers relevant to this problem, and following that > is a description of my trouble-shooting to date. > > NOTE: I simply refer to the two computers as "tulip" and "ne2k" as those > are generic descriptions of the installed NICs and the easiest way to > distinguish between the two computers on a mailing-list specifically > concerning NIC drivers. > > tulip: > Netgear FA310TX PCI > Red Hat 6.1 > kernel 2.2.12-20 > tulip.c v0.89H 5/23/98 and upgraded to v0.92 4/17/2000 > circa '98-'99 PII-450 (440BX chipset) > > ne2k: > Netgear EA201c > Red Hat 6.1 > kernel 2.2.12-20 > ne.c v1.10 9/23/94 > circa '94 486 (ISA & VLB only) > > connected by cat5 crossover cable > > EDITORIAL NOTE: Hardware addresses withheld due to privacy concerns. If > the hardware addresses are really necessary for trouble-shooting, then > please request that I mail them directly to your email address, and not to > a public forum. > > --- dmesg on tulip --- > > tulip.c:v0.92 4/17/2000 Written by Donald Becker > http://www.scyld.com/network/tulip.html > eth0: Lite-On 82c168 PNIC rev 32 at 0xc40f1000, **:**:**:**:**:**, IRQ 5. > eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. > > --- /var/log/messages on tulip --- > > no errors or any references > > --- eth0 in /proc/net/dev on tulip --- > > Receive > bytes packets errs drop fifo frame compressed multicast > 1008022 1427 523 0 0 1046 0 0 > Transmit > bytes packets errs drop fifo colls carrier compressed > 1662749 1855 307 0 0 276 307 0 > > --- ifconfig eth0 on tulip --- > > Link encap:Ethernet HWaddr **:**:**:**:**:** > inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1427 errors:523 dropped:0 overruns:0 frame:1046 > TX packets:1855 errors:307 dropped:0 overruns:0 carrier:307 > collisions:276 txqueuelen:100 > Interrupt:5 Base address:0x1000 > > --- mii-diag on tulip --- > > mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Basic registers of MII PHY #1: 3000 782d 0040 6212 01e1 0021 0000 0000. > Basic mode control register 0x3000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > Your link partner is generating 10baseT link beat (no autonegotiation). > > --- tulip-diag on tulip --- > > tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xd400. > Port selection is MII, half-duplex. > Transmit started, Receive started, half-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 72. > MII PHY found at address 1, status 0x782d. > MII PHY #1 transceiver registers: > 3000 782d 0040 6212 01e1 0021 0000 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 5000 0000 0000 0000 0000 0000 0300 0000 > 003c 8006 0f00 ff00 002c 4000 0080 000b. > Basic mode control register 0x3000: Auto-negotiation enabled. > Basic mode status register 0x782d ... 782d. > Link status: established. > Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. > Able to perform Auto-negotiation, negotiation complete. > Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. > No specific information is known about this transceiver type. > I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT > Advertising no additional info pages. > IEEE 802.3 CSMA/CD protocol. > Link partner capability is 0021: 10baseT. > Negotiation did not complete. > > --- dmesg on ne2k --- > > ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov) > NE*000 ethercard probe at 0x300: ** ** ** ** ** ** > eth0: NE2000 found at 0x300, using IRQ 10. > > --- /var/log/messages on ne2k --- > > no errors or any references > > --- eth0 in /proc/net/dev on ne2k --- > > Receive > bytes packets errs drop fifo frame compressed multicast > 1667226 1940 0 0 0 230 0 1 > Transmit > bytes packets errs drop fifo colls carrier compressed > 1562737 2043 0 0 0 0 0 0 > > --- ifconfig eth0 on ne2k --- > > Link encap:Ethernet HWaddr **:**:**:**:**:** > inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1933 errors:0 dropped:0 overruns:0 frame:230 > TX packets:2036 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > Interrupt:10 Base address:0x300 > > --- ne2k-diag on ne2k --- > > ne2k-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > Checking the ethercard at 0x300. > Receive alignment error counter (0x30d) is ff > Passed initial NE2000 probe, value 00. > Station Address PROM 0: ** ** ** ** ** ** ** ** ** ** ** ** 00 00 00 00 > Station Address PROM 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 57 57 57 57 > NE2000 found at 0x300, using start page 0x40 and end page 0x80. > The current MAC stations address is **:**:**:**:**:**. > 8390 page 0: 20 ff ff 7a 42 00 ff 00 20 00 7b ff 21 00 00 00. > 8390 page 1: 60 ** ** ** ** ** ** 7b 00 00 00 80 00 ff 00 00. > 8390 page 2: 00 ff 49 ff 49 ff 49 ff 49 ff 49 ff 49 ff 49 ff. > 8390 page 3: e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff. > > --- > > What have I tried so far? I noticed that the tulip was the one screaming > about errors, so I assume (very possibly incorectly) that the problem lies > with it. The network slowdown is also greatest when transfering from tulip > to ne2k. (Though that doesn't really suggest anything as the problem could > be ne2k RX and not necessarily tulip TX.) That's why I'm posting to this > tulip mailing-list, instead of the ne2k mailing-list (if one even > exists). I've also focused most of my trouble-shooting on the tulip. > > Since all the errors were on the tulip, I first thought maybe it was the > tulip driver. So I upgraded to v0.92 from netdriver-2.0-2.src.rpm. No > improvement. Tulip dual-boots between linux and win98, so I transfered > (ftp) files between tulip (in both OSes) and ne2k, and based on throughput > numbers win98 is quite faster, which makes me believe the problem is > driver-based and not hardware-based. But I don't know of a ifconfig or > /proc/net/dev equivalent in win98, so maybe the problem of massive errors > still exists in win98, I just can't see the errors. > > I then started reading the mailing-list archives and saw a mention of bad > cabling. "Duh," I thought, but I don't have a spare known-working > crossover cable (nor do we have them in general use at work for me to > borrow overnight) to test with. But if the problem was with the cabling > wouldn't there be errors reported on both computers instead of all (TX and > RX) on one end? I did flip-flop which end of the crossover cable was > plugged into which computer, but all the errors continued to be reported by > tulip. If this is very possibly the problem, then I'll purchase another > crossover cable for testing, but I would prefer to not have to. > > I've checked the simple configuration stuff like IRQ, but that doesn't seem > to be the problem. Both cards are recognized with no problems reported, so > it makes me believe it's something else besides driver configuration, like > the driver itself. > > Oh, I don't think it's the TCP/IP stack, as I use to have these machines > connected by PLIP, and never encountered any problems (besides balancing > the use of the parallel port with both PLIP and a printer). > > I am unable to solve the problem, and short of testing (which requires > buying) a new crossover cable and new NICs, I don't know what to test or > try next. > > I apologize if the problem/solution is obvious from the above information, > and I've just happened to be blind to it. If that's the case, then I am > sorry I wasted your time and bandwidth, but please still inform me of the > solution (with whatever ridicule you fill necessary). > > Thank you in advance for your assistance. > > C o r e y W r i g h t > mailto:undefined@pobox.com > http://zeros-ones.homepage.com/Corey-Wright-public-key.html > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip -- Jason Thomas Phone: +61 2 6257 7111 System Administrator - UID 0 Fax: +61 2 6257 7311 tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ --HB4mHL4PVvkpZAgW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: fyArkbuBc9/fOp+lb1kvYw7iAE7HWguq Comment: Ha Ha iQA/AwUBOSosyu3GMESSUoi+EQLYAQCeIvaJEEGcn4m7RViy9VAcByQoGvUAnidR D6yFq0vyAkI2CWf9kLh4QqOI =1lXi -----END PGP SIGNATURE----- --HB4mHL4PVvkpZAgW-- From becker@scyld.com Tue, 23 May 2000 03:34:32 -0400 (EDT) Date: Tue, 23 May 2000 03:34:32 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip] ton o' errors with netgear NIC On Tue, 23 May 2000 undefined@engineer.com wrote: > In my home I have 2 computers, each with a Netgear card, connected merely > by a crossover cable. Under light network-traffic loads running .. > connected by cat5 crossover cable > > EDITORIAL NOTE: Hardware addresses withheld due to privacy concerns. If There is no reason to go to the effort. The most malicious thing someone could do with the info is trigger Wake-On-LAN, but your boards don't support Wake-On-LAN. > tulip.c:v0.92 4/17/2000 Written by Donald Becker > http://www.scyld.com/network/tulip.html > eth0: Lite-On 82c168 PNIC rev 32 at 0xc40f1000, **:**:**:**:**:**, IRQ 5. > eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. > Receive > bytes packets errs drop fifo frame compressed multicast > 1008022 1427 523 0 0 1046 0 0 > Transmit > bytes packets errs drop fifo colls carrier compressed > 1662749 1855 307 0 0 276 307 0 You might have a bad crossover cable. It's probably mispaired. Or your link partner might be set to forced full duplex. > MII PHY #1 transceiver registers: > 3000 782d 0040 6212 01e1 0021 0000 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 5000 0000 0000 0000 0000 0000 0300 0000 > 003c 8006 0f00 ff00 002c 4000 0080 000b. > Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. > No specific information is known about this transceiver type. What transceiver type are you using? > ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov) > NE*000 ethercard probe at 0x300: ** ** ** ** ** ** > eth0: NE2000 found at 0x300, using IRQ 10. > Receive > bytes packets errs drop fifo frame compressed multicast > 1667226 1940 0 0 0 230 0 1 > Transmit > bytes packets errs drop fifo colls carrier compressed > 1562737 2043 0 0 0 0 0 0 Hmmm, no collisions. Very, very suspicious. I'm guessing forced-full-duplex at this point. > What have I tried so far? I noticed that the tulip was the one screaming > about errors, so I assume (very possibly incorectly) that the problem lies > with it. The network slowdown is also greatest when transfering from tulip Nope. It's almost certainly a configuration or hardware error. > RX) on one end? I did flip-flop which end of the crossover cable was > plugged into which computer, but all the errors continued to be reported by > tulip. If this is very possibly the problem, then I'll purchase another > crossover cable for testing, but I would prefer to not have to. I've been buying Belkin crossover cables from buy.com. They are cheap, and clearly coded with grey molded ends on a yellow cable. This isn't a specific endorsement for Buy.com, but they do have good prices right now. They must be operating at big loss to have low prices and such bad shipping practices -- one of my orders came with one cable per box! Anyway, check the forced-full-duplex setting on the NE2000 card. Donald Becker becker@scyld.com Scyld Computing Corporation 410 Severn Ave. Suite 210 Annapolis MD 21403 From cbrown@denalics.net Tue, 23 May 2000 08:35:28 -0900 (HADT) Date: Tue, 23 May 2000 08:35:28 -0900 (HADT) From: Christopher E. Brown cbrown@denalics.net Subject: [tulip] Re: Kingston On Tue, 23 May 2000, Homer Wilson Smith wrote: > > Am very confused here, I have been using the KNE100TX units, 1 > > - 4 per box for some time. When the 21143 units started arriving it > > was fun, but as soon as I switched from 89h everything was happy > > again. I checked, the 15 21143 KNE100TX cards are talking to Catalyst > > 2900 series units. All drop straight into 100FD, and more than a few > > hold 80Mbit+ each way during office hrs (Linux based filtering > > firewalls, and MASQ boxes). > > 2900 series is 100baseT , we are using 1900 which has > 10baseT ports. The 21143's work fine in 100baseT mode. > > Homer Hmm, just loaded the last release NMP/DMP for my Catalyst 1201 and brought into the office. At home it was talking to 21140 KNE100TX units at 10FD, same at the office with the 21143 cards, drops right to 10FD unless overridden. I am not doubting there are issues on the Cisco end here, just trying to narrow down the product lines and whatnot. Given their habit of buying a /neat/ company, and after re-badging dropping their new product in the middle of the product line there can be some major differences between what are supposed to be similar devices. --- As folks might have suspected, not much survives except roaches, and they don't carry large enough packets fast enough... --About the Internet and nuclear war. From homer@lightlink.com Tue, 23 May 2000 15:45:00 -0400 (EDT) Date: Tue, 23 May 2000 15:45:00 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] Re: Kingston > I am not doubting there are issues on the Cisco end here, just > trying to narrow down the product lines and whatnot. Given their > habit of buying a /neat/ company, and after re-badging dropping their > new product in the middle of the product line there can be some major > differences between what are supposed to be similar devices. You mean like Netspeed and Aironet :) I am using Cisco 1912's and 1924's exclusively. I just can't get the 21143's to work. The tulip-diag SAYS they are in full dup, but the green light is not on, and packet throughput is very slow with lots of runt frames, which is classic symptoms of card being in half duplex and cisco being in full. Don't know though, maybe something else is going on. Homer > > --- > As folks might have suspected, not much survives except roaches, > and they don't carry large enough packets fast enough... > --About the Internet and nuclear war. > > From homer@lightlink.com Tue, 23 May 2000 19:16:32 -0400 (EDT) Date: Tue, 23 May 2000 19:16:32 -0400 (EDT) From: Homer Wilson Smith homer@lightlink.com Subject: [tulip] Cisco 1900 + 21143 Running two linux 2.0.36 boxes connected to a Cisco 1900 switch, I got the following speeds and behavior trying to put box B into full dup mode. Box A is already in Full Dup using a 21140, Cisco 1900 ports are forced full dup 10 base T, not 100 base T. K is KiloBytes/second using ftp from B to A. HD means tupli-diag shows half duplex, Runts means Cisco is showing lots of runt frames. Cisco light blinks, means the green light slowly turns on and off, rather than just turning on, like it was trying over and over to negotiate something. Box A is 21140 Option Box B 21140 Box B 21143 0 HD 200K with Runts HD 200K with Runts 16 1100K No packets transfer 4 1100K No packets transfer 20 1100K No packets transfer 10 1100K Cisco light blinks, card light off 26 1100K Cisco light blinks, card light off 11 HD 200K Runts HD 250K Runts 27 1100K No packets transfer ------------------------------------------------------------------------ Homer Wilson Smith Clear Air, Clear Water, Art Matrix - Lightlink (607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY homer@lightlink.com Is that too much to ask? http://www.lightlink.com From jason@topic.com.au Wed, 24 May 2000 09:39:10 +1000 Date: Wed, 24 May 2000 09:39:10 +1000 From: Jason Thomas jason@topic.com.au Subject: [tulip] Re: Kingston --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The duplex light is controlled by software on the tulip cards, this requires code for each of the different cards/chips in the range, according to Donald. Homer Wilson Smith [homer@lightlink.com] wrote: > > I am not doubting there are issues on the Cisco end here, just > > trying to narrow down the product lines and whatnot. Given their > > habit of buying a /neat/ company, and after re-badging dropping their > > new product in the middle of the product line there can be some major > > differences between what are supposed to be similar devices. > > You mean like Netspeed and Aironet :) > > I am using Cisco 1912's and 1924's exclusively. I just > can't get the 21143's to work. The tulip-diag SAYS they > are in full dup, but the green light is not on, and packet > throughput is very slow with lots of runt frames, which is > classic symptoms of card being in half duplex and cisco being > in full. Don't know though, maybe something else is going on. > > Homer > > > > > --- > > As folks might have suspected, not much survives except roaches, > > and they don't carry large enough packets fast enough... > > --About the Internet and nuclear war. > > > > > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip -- Jason Thomas System Administrator - UID 0 Phone: +61 2 6257 7111 tSA Consulting Group Pty. Ltd. Fax: +61 2 6257 7311 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: 1geV4FKF98lqrBcRmW8jNJFVzrxsxotk Comment: Ha Ha iQA/AwUBOSsWnu3GMESSUoi+EQJ6IACfT+jM2XQnimUkAeJWuZO53zbeOUIAoJUa 73Q8//OgcB65xdFvrnNXNv1J =7AuK -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From pogosyan@cita.utoronto.ca Thu, 25 May 2000 00:04:24 -0400 Date: Thu, 25 May 2000 00:04:24 -0400 From: Dmitri Pogosyan pogosyan@cita.utoronto.ca Subject: [tulip] NWay status register How do I decode the NWay status register which is reported by tulip-diag ? In my case it reads ............ The NWay status register is 41e1d0cc ............ Thanks, Dmitri Pogosyan From dixon@webwork.co.uk Thu, 25 May 2000 10:03:04 +0100 Date: Thu, 25 May 2000 10:03:04 +0100 From: Tim Dixon dixon@webwork.co.uk Subject: [tulip] Re: More DFE-570TX Tx Hung Problems Just to update Donald and the several other people who've expressed interest in this... > [Just to summarise; we've been getting "Tx Hung" errors where we have > several DFE-570TXs in one box so that some of the ports end up > sharing IRQs. Simply ifconfig'ing the stuck port up and down makes > no difference. Other ports on the same card continue to work. >/proc/interrupts revealed that no interrupts were being taken on the >IRQ shared by the ports concerned. Although ifconfiging down the stuck >port didn't make any difference, taking down ALL the ports sharing the >IRQ and bringing them back up again seemed to do the trick. >We've had the same problem on a couple of different IRQ lines in the >same machine (in each case, 3 ports shared an IRQ)] We've found the same problem running driver V0.92 and I'm seriously starting to suspect the motherboard rather than the devices or the drivers. It looks like the devices believe they have an interrupt request pending on the shared IRQ but it isn't being delivered. My guess is that a condition arises in which two simultaneous interrupts on the same IRQ are mishandled by the arbitration hardware and it is essentially waiting for the interrupt requests to be cleared before recognising another interrupt - which will never happen because it's the ISR that clears the requests (effectively that the hardware is behaving in an edge-triggered rather than level-triggered manner). We've built a similar system with a different brand of motherboard and have during initial testing experience no similar problems. We'll replace the system in the field later in the week and see if the problems go away. Tim From becker@scyld.com Thu, 25 May 2000 11:26:45 -0400 (EDT) Date: Thu, 25 May 2000 11:26:45 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip] NWay status register On Thu, 25 May 2000, Dmitri Pogosyan wrote: > How do I decode the NWay status register which is reported > by tulip-diag ? In my case it reads > > ............ > The NWay status register is 41e1d0cc > ............ The upper word is the link partner's code word 0x41e1 Autonegotiation worked, and you are talking to a 10+100/HD+FD switch. This confirms that you have a working SYM transceiver. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Annapolis MD 21403 From nobody@mixmaster.shinn.net Fri, 26 May 2000 07:59:08 -0400 Date: Fri, 26 May 2000 07:59:08 -0400 From: Anonymous Sender nobody@mixmaster.shinn.net Subject: [tulip] The REALLY problem of Transmit-Timout! Hi for all! I have a little network with one Linux server (Pentium II 350MHz 256MB RAM 2x8GB IDE) and four Windows98 workstations (different CPU / RAM / HD / NIC / VGA). From last 2 years I have upgrade the Linux box with different distributions & kernels (RH 5.x/6.x, Mandrake 5.x/6.x, kernels 2.0.x/2.2.x). I use Samba (from 2.0.0 to 2.0.7) on Linux for emulate a NT server (very good). The problem are the continuos TRANSMIT ERROR (timeouts) in the network. To test the network I make 'ping �t server' in any Windows client, and when 'transmit timeout' occurs I need to manually restart the HUB. With this the network restart, and we can continue out job. This problem occurs randomly: days no, days little, days heavy... I have tested with TWO different HUBS (one 100MB x 8 ports / actually 10/100 x 8 ports); and TWO different NICs on Linux box: 3Com 905B PCI and Intel EEPRO 100+ PCI. I installed more than 20 drivers for two NICs (originals from kernel source, modified from official "Linux Network Drivers' at SCYLD (old on NASA server), modified from different people at mailing list on TUX, betas, and official drivers from 3Com and Intel), with different options (Multicast limit, max_interrupt, debug), and different compile variations (gcc/pgcc, -O/O2/O6). WITH ALL I have problems, but... I have read most messages from last 8 moth on mailing list on TUX, for 3Com 59x/90x NIC, EEPRO100 NIC and Digital 21*4* NIC. On ALL lists there are people with TIMEOUTS PROBLEMS. You think that the problem is on hardware? I think NO !!!!! (Please test I said, the are messages for all different hardware: http://www.tux.org/hypermail/linux-vortex/ ; http://www.tux.org/hypermail/linux-tulip/ ; http://www.tux.org/hypermail/linux-eepro100/ ) If I restart eth0 with ifconfig, the network restart; if I power off-on the Hub, the network restart; if I unplug-plug any network wire of the network, the network... obviously... restart. FROM ALL THIS... PLEASE!, make a modified driver, that when RESTART de NIC, restart ALL components (chip, transceiver, queues) and, THIS IS THE MOST IMPORTANT, "RESTART THE ETHERNET INTERFACE WITH THE KERNEL". I think the problem is on the queues with Ethernet interface (at O.S. level): at moment you don't flush queues after a network error, or no restart send-receive status after restart NIC. Is this possible? What you think? Please, send any comment, or Transmit-Timeout problem continues... at eternum! Thanks for all! LARS18TH From alhaz@xmission.com Fri, 26 May 2000 07:41:10 -0600 (MDT) Date: Fri, 26 May 2000 07:41:10 -0600 (MDT) From: Eric Jorgensen alhaz@xmission.com Subject: [tulip] The REALLY problem of Transmit-Timout! Somebody is going to slap me for suggesting this, but have you tried the same problematic NICs and other sundry equipment with different motherboards? I'm not saying there isn't a problem -- but i think you have a PCI issue. Otherwise, *everyone* would be experiencing this kind of thing. Right now I manage on the order of about 30 Intel 82559's and about 20 Lite-On LNE100tx's under various versions of Linux from 2.2.5 to 2.2.15. The *ONLY* ones that had problems were the systems with decidedly funky PCI busses - APPRO branded active backplane systems with single-board SMP PII cards. These beasts have like 3 completely dissimilar PCI host bridges in them and for some reason no PCI nic is completely happy in them. That being said, not all of the APPRO boxes here have PCI issues - just the two most important ones (DNS servers). I have three web servers in identical hardware that have never had a problem. - Eric > > Hi for all! > > I have a little network with one Linux server (Pentium II 350MHz 256MB RAM 2x8GB IDE) and four Windows98 workstations (different CPU / RAM / HD / NIC / VGA). From last 2 years I have upgrade the Linux box with different distributions & kernels (RH 5.x/6.x, Mandrake 5.x/6.x, kernels 2.0.x/2.2.x). I use Samba (from 2.0.0 to 2.0.7) on Linux for emulate a NT server (very good). > > The problem are the continuos TRANSMIT ERROR (timeouts) in the network. To test the network I make 'ping �t server' in any Windows client, and when 'transmit timeout' occurs I need to manually restart the HUB. With this the network restart, and we can continue out job. This problem occurs randomly: days no, days little, days heavy... > > I have tested with TWO different HUBS (one 100MB x 8 ports / actually 10/100 x 8 ports); and TWO different NICs on Linux box: 3Com 905B PCI and Intel EEPRO 100+ PCI. I installed more than 20 drivers for two NICs (originals from kernel source, modified from official "Linux Network Drivers' at SCYLD (old on NASA server), modified from different people at mailing list on TUX, betas, and official drivers from 3Com and Intel), with different options (Multicast limit, max_interrupt, debug), and different compile variations (gcc/pgcc, -O/O2/O6). WITH ALL I have problems, but... From marco.flohrer@informatik.tu-chemnitz.de Fri, 26 May 2000 20:37:44 +0200 (MET DST) Date: Fri, 26 May 2000 20:37:44 +0200 (MET DST) From: Marco Flohrer marco.flohrer@informatik.tu-chemnitz.de Subject: [tulip] Cogent Quartet EM400TX <-crossover-> SMC EtherPower 10/100 Dual Hello! I now have one port of my EM400TX connected via crossover cable to one port of my SMC EtherPower 10/100 Dual. Bootup-messages of these cards: (only the used port) SMC: eth0: Digital DS21140 Tulip rev 32 at 0xd800, 00:E0:29:25:23:89, IRQ 10. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. eth0: MII transceiver #3 config 3100 status 7809 advertising 01e1. eth0: Advertising 0101 on PHY 3, previously advertising 01e1. eth0: Advertising 0101 (to advertise is 0100). Cogent: eth2: Digital DS21140 Tulip rev 32 at 0xb800, 00:00:92:95:2A:C8, IRQ 12. eth2: EEPROM default media type Autosense. eth2: Index #0 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth2: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. I force booth Cards with an lilo-option to 100BaseTX-FD, which seems to work. But: I have to 'ifconfig eth2 down; ifconfig eth2 up' to reinitialize the Cogent after the maschine with the SMC has booted up to get the link work. What is the reason for this? If i use an Dlink DFE500TX as replasement for one of both cards, there is no problem. -- Now STRONGARMed and dangerous! No RISC, no fun! :) mailto: marco.flohrer@informatik.tu-chemnitz.de talk: mafl@diamond.csn.tu-chemnitz.de From phil@asu.com Sun, 28 May 2000 19:30:55 +0200 Date: Sun, 28 May 2000 19:30:55 +0200 From: Philipp Schulte phil@asu.com Subject: [tulip] ASIX AX88140 Hello, I have a rather stange problem: I am using an ASIX AX88140 with the Linux-Kernel 2.2.15. If I choose the old_tulip-module the card works fine except one thing. I can not establish any connection from an other Client. There is just no reply. But if I ping the other client from the ASIX AX88140 everytings works fine. It seems like the card needs to wake up first. The card is described in /var/log/messages as follows: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: ASIX AX88140 rev 16 at 0xd800, 00:50:00:00:03:1C, IRQ 10. eth0: EEPROM default media type 100baseTx. eth0: Index #0 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth0: ***WARNING***: No MII transceiver found! eth0: Using EEPROM-set media 100baseTx. OK, I decided to try the tulip-module. I can load it without any problems, and I can ping myself but not any other client. The connection seems to be dead. Then I downloaded the current tulip-driver and compiled it. When I want to load the module I get the following output: nepomuk:/usr/src/linux/modules # insmod tulip Using /lib/modules/2.2.15/net/tulip.o /lib/modules/2.2.15/net/tulip.o: unresolved symbol pci_drv_unregister /lib/modules/2.2.15/net/tulip.o: unresolved symbol pci_drv_register I took a look at the source but don't feel like I should change anything. What did I do wrong? Will the new tulip-driver be able to correct the "wake-up"-ping problem? Thanks a lot, Phil From philipp.schulte@arcormail.de Sun, 28 May 2000 20:17:26 +0200 Date: Sun, 28 May 2000 20:17:26 +0200 From: Philipp Schulte philipp.schulte@arcormail.de Subject: [tulip] ASIX AX88140 Hello, in my prior mail the "From:"-part was broken due to a misconfugured sender_cannonical. It was fixed now, sorry. Phil From becker@scyld.com Sun, 28 May 2000 16:52:08 -0400 (EDT) Date: Sun, 28 May 2000 16:52:08 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip] ASIX AX88140 On Sun, 28 May 2000, Philipp Schulte wrote: > I am using an ASIX AX88140 with the Linux-Kernel 2.2.15. If I choose > the old_tulip-module the card works fine except one thing. I can not > establish any connection from an other Client. There is just no > reply. But if I ping the other client from the ASIX AX88140 everytings > works fine. It seems like the card needs to wake up first. .. > tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov > eth0: ASIX AX88140 rev 16 at 0xd800, 00:50:00:00:03:1C, IRQ 10. This is a know bug in that driver version. The 88140 has a different Rx filter than the 21140: it does not enable broadcast reception in the same way. > OK, I decided to try the tulip-module. I can load it without any > problems, and I can ping myself but not any other client. The > connection seems to be dead. > Then I downloaded the current tulip-driver and compiled it. When I > want to load the module I get the following output: > > nepomuk:/usr/src/linux/modules # insmod tulip > Using /lib/modules/2.2.15/net/tulip.o > /lib/modules/2.2.15/net/tulip.o: unresolved symbol pci_drv_unregister > /lib/modules/2.2.15/net/tulip.o: unresolved symbol pci_drv_register You need to load "pci-scan.o" first. Read http://www.scyld.com/network/updates.html Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Annapolis MD 21403 From Jim@Morris.net Mon, 29 May 2000 04:02:04 -0500 Date: Mon, 29 May 2000 04:02:04 -0500 From: Jim Morris Jim@Morris.net Subject: [tulip] Problems loading Tulip modules in 2.2.15 kernel Hi all. I'm having a strange problem here.... I've built a Linux 2.2.15 kernel, using the tulip and old_tulip modules included. Works great on my uniprocessor system. I tarred up the kernel directory, and then unpacked the it on my SMP system, and built with IDENTICAL kernel compile-time options EXCEPT for the SMP support option. I.e. all I changed in "make menuconfig" was that one option. When trying to load the tulip or old_tulip modules, I get an error like this: [root@darkstar /root]# modprobe old_tulip /lib/modules/2.2.15-jfm/net/old_tulip.o: unresolved symbol __global_cli /lib/modules/2.2.15-jfm/net/old_tulip.o: unresolved symbol __global_save_flags /lib/modules/2.2.15-jfm/net/old_tulip.o: unresolved symbol __global_restore_flas That got chopped off a little pasting it between windows, but you get the picture. Is there some sort of problem with the stock tulip drivers on an SMP 2.2.15 kernel? Or do I have something else going on here.... Thanks! BTW, I have a reason that I need to use an older driver, and not the latest available. This system has two Linksys LNE100TX cards that only work with the Linksys supplied driver. So in reality, I started off trying to use the Linksys driver, and saw the problem. But switching to the kernel supplied modules makes no difference... Again, thanks for any suggestions... -- /-----------------------------\ | Jim Morris | Jim@Morris.net | \-----------------------------/ From philipp.schulte@arcormail.de Mon, 29 May 2000 13:55:39 +0200 Date: Mon, 29 May 2000 13:55:39 +0200 From: Philipp Schulte philipp.schulte@arcormail.de Subject: [tulip] ASIX AX88140 On Sun, May 28, 2000 Donald Becker wrote: > On Sun, 28 May 2000, Philipp Schulte wrote: > > nepomuk:/usr/src/linux/modules # insmod tulip > > Using /lib/modules/2.2.15/net/tulip.o > > /lib/modules/2.2.15/net/tulip.o: unresolved symbol pci_drv_unregister > > /lib/modules/2.2.15/net/tulip.o: unresolved symbol pci_drv_register > > You need to load "pci-scan.o" first. OK, I loaded it and tried to load the tulip-module afterwards. insmod says: "Device or recourse busy". /var/log/messages says: "Failed to map PCI address 0x0 for device 'ASIX AX88141'" What am I doing wrong? Why does the new tulip-driver say I am using a AX88141 while the old one said I am using an AX88140? Thanks for your help, Phil From tabt@gmx.de Mon, 29 May 2000 17:55:35 +0200 Date: Mon, 29 May 2000 17:55:35 +0200 From: Tobias Abt tabt@gmx.de Subject: [tulip] v0.92: "transmit timed out" problems Using a CNet 100TX(E) 21143 Tulip based card (against a ne2k-pci board) I get "transmit timed out" problems with v0.92 while older versions (0.89 and v0.91*) work perfectly, even with automatic media detection. I also have the similar problems with my other tulip based card (Allnet 8832). Seems to be a general problem... This is the output of "lspci -v": 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) Subsystem: Accton Technology Corporation Cheetah Fast Ethernet Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at b000 Memory at dd800000 (32-bit, non-prefetchable) (wrong manufacturer/device ids, seems to be pretty common with standard cards?) If I start the driver with "options=12" to force 10base-T, I get this output: May 17 18:16:24 banshee kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 17 18:16:24 banshee kernel: http://www.scyld.com/network/tulip.html May 17 18:16:24 banshee kernel: eth0: Digital DS21143 Tulip rev 48 at 0xc884a000, 00:80:AD:83:54:E4, IRQ 10. May 17 18:16:24 banshee kernel: eth0: EEPROM default media type Autosense. May 17 18:16:24 banshee kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. May 17 18:16:24 banshee kernel: eth0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. May 17 18:16:24 banshee kernel: eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. May 17 18:16:24 banshee kernel: eth0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. May 17 18:16:25 banshee named[127]: ns_forw: sendto([193.0.14.129].53): Network is unreachable May 17 18:16:25 banshee kernel: eth0: Using user-specified media 10baseT(forced). May 17 18:17:05 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fff8ffff 8ffd0008, resetting... May 17 18:17:30 banshee last message repeated 2 times May 17 18:20:45 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fff8ffff 8ffd0008, resetting... May 17 18:21:55 banshee last message repeated 7 times May 17 18:22:55 banshee last message repeated 6 times May 17 18:23:55 banshee last message repeated 6 times May 17 18:24:55 banshee last message repeated 6 times May 17 18:25:35 banshee last message repeated 4 times If I use the driver without any options I get: May 17 17:10:30 banshee kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker May 17 17:10:30 banshee kernel: http://www.scyld.com/network/tulip.html May 17 17:10:30 banshee kernel: eth0: Digital DS21143 Tulip rev 48 at 0xc884a000, 00:80:AD:83:54:E4, IRQ 10. May 17 17:10:30 banshee kernel: eth0: EEPROM default media type Autosense. May 17 17:10:30 banshee kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. May 17 17:10:30 banshee kernel: eth0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. May 17 17:10:30 banshee kernel: eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. May 17 17:10:30 banshee kernel: eth0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. May 17 17:13:05 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fffbffff 8ffd0008, resetting... May 17 17:13:05 banshee kernel: eth0: transmit timed out, switching to 100baseTx-FDX media. May 17 17:13:20 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fffbffff 8ffd0008, resetting... May 17 17:13:20 banshee kernel: eth0: transmit timed out, switching to 100baseTx-FDX media. May 17 17:13:35 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fffbffff 8ffd0008, resetting... May 17 17:13:35 banshee kernel: eth0: transmit timed out, switching to 100baseTx-FDX media. May 17 17:13:50 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fffbffff 8ffd0008, resetting... May 17 17:13:50 banshee kernel: eth0: transmit timed out, switching to 100baseTx-FDX media. May 17 17:14:05 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fffbffff 8ffd0008, resetting... May 17 17:14:05 banshee kernel: eth0: transmit timed out, switching to 100baseTx-FDX media. May 17 17:14:20 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fffbffff 8ffd0008, resetting... May 17 17:14:20 banshee kernel: eth0: transmit timed out, switching to 100baseTx-FDX media. May 17 17:14:35 banshee kernel: eth0: 21140 transmit timed out, status f0660000, SIA 000052ca ffff0001 fffbffff 8ffd0008, resetting... May 17 17:14:35 banshee kernel: eth0: transmit timed out, switching to 100baseTx-FDX media. The output of "tulip-diag -vee": tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xb000. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000000c6. EEPROM size is 6. PCI Subsystem IDs, vendor 1113, device 1207. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:AD:83:54:E4. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 00a5. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 00a5. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). Media 100baseTx Full Duplex, block type 4, length 8. SYM transceiver for 100baseTx Full Duplex (media type 5). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). EEPROM contents: 1113 1207 0000 0000 0000 0000 0000 0000 0090 0104 8000 83ad e454 1e00 0000 0800 8604 0002 08af 00a5 0286 af04 a508 8800 0304 08af 00a5 8061 0488 af05 a508 6100 0080 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 54bf ID block CRC 0x90 (vs. 0x90). Full contents CRC 0x54bf (read as 0x54bf). Internal autonegotiation state is 'Autonegotiation disabled'. Bye, \|/ Tobias @ @ +----------------oOO-(_)-OOo-----------+ | Tobias Abt | | email: tabt@gmx.de | +--------------------------------------+ From tabt@gmx.de Mon, 29 May 2000 17:56:54 +0200 Date: Mon, 29 May 2000 17:56:54 +0200 From: Tobias Abt tabt@gmx.de Subject: [tulip] Re: Allnet 8832 almost working with v0.92 tulip driver I have some more information concerning my card: tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xb800. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. PCI Subsystem IDs, vendor 1109, device 2b00. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:E0:7D:70:05:1E. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 40, default media type 0800 (Autosense). 2 transceiver description blocks: MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0001. 21143 MII reset sequence is 3 words: 0821 0001 0001. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. Serial transceiver for 10base2 (media type 65). mdio_read(0xb800, 0, 1).. mdio_read(0xb800, 1, 1).. MII PHY found \ at address 1, status 0x782d. mdio_read(0xb800, 2, 1).. mdio_read(0xb800, 3, 1).. mdio_read(0xb800, 4, 1).. mdio_read(0xb800, 5, 1).. mdio_read(0xb800, 6, 1).. mdio_read(0xb800, 7, 1).. mdio_read(0xb800, 8, 1).. mdio_read(0xb800, 9, 1).. mdio_read(0xb800, 10, 1).. mdio_read(0xb800, 11, 1).. mdio_read(0xb800, 12, 1).. mdio_read(0xb800, 13, 1).. mdio_read(0xb800, 14, 1).. mdio_read(0xb800, 15, 1).. mdio_read(0xb800, 16, 1).. mdio_read(0xb800, 17, 1).. mdio_read(0xb800, 18, 1).. mdio_read(0xb800, 19, 1).. mdio_read(0xb800, 20, 1).. mdio_read(0xb800, 21, 1).. mdio_read(0xb800, 22, 1).. mdio_read(0xb800, 23, 1).. mdio_read(0xb800, 24, 1).. mdio_read(0xb800, 25, 1).. mdio_read(0xb800, 26, 1).. mdio_read(0xb800, 27, 1).. mdio_read(0xb800, 28, 1).. mdio_read(0xb800, 29, 1).. mdio_read(0xb800, 30, 1).. mdio_read(0xb800, 31, 1).. Internal autonegotiation state is 'Autonegotiation disabled'. mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html MII PHY #32 transceiver registers: 0000 7848 0000 0000 0441 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x7848 ... 7848. Link status: not established. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Link partner information information is not exchanged when in fixed speed mode. MII PHY #32 transceiver registers: 0000 7848 0000 0000 0441 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled! Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x7848 ... 7848. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. This transceiver has no vendor identification. I'm advertising 0441: Flow-control 10baseT-FD Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Some ftp transfer (upload) results (100Mbit/FD autonegotiated): 4875493 bytes sent in 147.10 seconds, 32.37 kB/s. 3359137 bytes sent in 54.74 seconds, 59.93 kB/s. 3469061 bytes sent in 78.92 seconds, 42.92 kB/s. 3023516 bytes sent in 53.20 seconds, 55.50 kB/s. 4671111 bytes sent in 130.77 seconds, 34.88 kB/s. 3079523 bytes sent in 113.96 seconds, 26.39 kB/s. during this I got two "Tx hung" messages. Ftp downloads do not works at all, they simply time out or get stuck. -- Bye, \|/ Tobias @ @ +----------------oOO-(_)-OOo-----------+ | Tobias Abt | | email: tabt@gmx.de | +--------------------------------------+ From parrishmyers@yahoo.com Mon, 29 May 2000 21:26:54 -0700 (PDT) Date: Mon, 29 May 2000 21:26:54 -0700 (PDT) From: Parrish M Myers parrishmyers@yahoo.com Subject: [tulip] tulip.c and Debian Potato Hi, I wanted to know if someone could tell me how to properly compile the tulip.c driver as a module for a debian potato distro. Currently I have searched the tulip and debian-user mailing list archives and followed all the suggestions. All help has seemed to fail. I have gotten to the point of compiling the driver as a module with only minor syntax warnings. The problem arrises when I try to load the module using the command insmod. The result allways seems to return this error message: /lib/modules/2.2.14/net/tulip.o: unresolved symbol netif_rx_Rsmp_4092cf24 /lib/modules/2.2.14/net/tulip.o: unresolved symbol alloc_skb_Rsmp_4e202d8c /lib/modules/2.2.14/net/tulip.o: unresolved symbol free_irq_Rsmp_f20dabd8 /lib/modules/2.2.14/net/tulip.o: unresolved symbol pcibios_write_config_word_Rsmp_4f1c2e33 /lib/modules/2.2.14/net/tulip.o: unresolved symbol securebits_Rsmp_abe77484 /lib/modules/2.2.14/net/tulip.o: unresolved symbol eth_copy_and_sum_Rsmp_6bcd57dd /lib/modules/2.2.14/net/tulip.o: unresolved symbol pcibios_write_config_dword_Rsmp_81b4f465 /lib/modules/2.2.14/net/tulip.o: unresolved symbol request_region_Rsmp_6d32b2d7 /lib/modules/2.2.14/net/tulip.o: unresolved symbol pcibios_read_config_byte_Rsmp_d80115e1 /lib/modules/2.2.14/net/tulip.o: unresolved symbol check_region_Rsmp_522f4d72 /lib/modules/2.2.14/net/tulip.o: unresolved symbol init_etherdev_Rsmp_b041fa5f /lib/modules/2.2.14/net/tulip.o: unresolved symbol pcibios_write_config_byte_Rsmp_719856ee /lib/modules/2.2.14/net/tulip.o: unresolved symbol pcibios_present_Rsmp_520a75b9 /lib/modules/2.2.14/net/tulip.o: unresolved symbol kfree_Rsmp_037a0cba /lib/modules/2.2.14/net/tulip.o: unresolved symbol printk_Rsmp_1b7d4074 /lib/modules/2.2.14/net/tulip.o: unresolved symbol unregister_netdev_Rsmp_b8709765 /lib/modules/2.2.14/net/tulip.o: unresolved symbol __kfree_skb_Rsmp_1b2e7891 /lib/modules/2.2.14/net/tulip.o: unresolved symbol pci_find_slot_Rsmp_454463b5 /lib/modules/2.2.14/net/tulip.o: unresolved symbol pcibios_find_class_Rsmp_ef333f7b /lib/modules/2.2.14/net/tulip.o: unresolved symbol kmalloc_Rsmp_93d4cfe6 /lib/modules/2.2.14/net/tulip.o: unresolved symbol eth_type_trans_Rsmp_cd896297 /lib/modules/2.2.14/net/tulip.o: unresolved symbol pcibios_read_config_word_Rsmp_aa9effd7 /lib/modules/2.2.14/net/tulip.o: unresolved symbol add_timer_Rsmp_bea990b2 /lib/modules/2.2.14/net/tulip.o: unresolved symbol release_region_Rsmp_43bde9b1 /lib/modules/2.2.14/net/tulip.o: unresolved symbol jiffies_Rsmp_0da02d67 /lib/modules/2.2.14/net/tulip.o: unresolved symbol request_irq_Rsmp_0c60f2e0 /lib/modules/2.2.14/net/tulip.o: unresolved symbol bh_active_Rsmp_fff9d0a3 /lib/modules/2.2.14/net/tulip.o: unresolved symbol skb_over_panic_Rsmp_2c5d3b6d /lib/modules/2.2.14/net/tulip.o: unresolved symbol del_timer_Rsmp_5811f067 /lib/modules/2.2.14/net/tulip.o: insmod /lib/modules/2.2.14/net/tulip.o failed /lib/modules/2.2.14/net/tulip.o: insmod tulip failed Does anyone have any other suggestions? I would appreciate it. The only reason I am tring to do this is because the Netgear FA-310TX card that I have comes up (during system boot) more or less broken and the only thing I can find to fix it is a ifdown -a followed by a ifup -a. Thanks Parrish M Myers ===== ----------------------------------------------------------- Academia is a little like child | Parrish M. Myers rearing, it provides a chance at | The Wacked Jester immortality without the stretch | parrishmm@earthlink.net marks -- (unknown source) | ----------------------------------------------------------- __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From jose@iteso.mx Tue, 30 May 2000 00:35:24 -0500 (CDT) Date: Tue, 30 May 2000 00:35:24 -0500 (CDT) From: =?iso-8859-1?Q?Jos=E9_A=2E_Guzm=E1n?= jose@iteso.mx Subject: [tulip] tulip.c and Debian Potato Parrish, you need to download the Makefile as indicated on http://www.scyld.com/network/updates.html then edit the line which says DRV_OFILES, and let only tulip.o there. You also need the include files and .c files as the above URL says under 'Installing Individual Drivers', then just type make and it'll create two modules, insert first the pci-scan, then the tulip one and you should be happy. Of course this applies to all the drivers modified to work with the new pci-scan scheme created by Donald. Cheers. Jos�. On Mon, 29 May 2000, Parrish M Myers wrote: > Hi, > > I wanted to know if someone could tell me how to properly compile the > tulip.c driver as a module for a debian potato distro. Currently I > have searched the tulip and debian-user mailing list archives and > followed all the suggestions. All help has seemed to fail. I have > gotten to the point of compiling the driver as a module with only minor > syntax warnings. The problem arrises when I try to load the module > using the command insmod. The result allways seems to return this > error message: > > /lib/modules/2.2.14/net/tulip.o: unresolved symbol > netif_rx_Rsmp_4092cf24 > /lib/modules/2.2.14/net/tulip.o: unresolved symbol > alloc_skb_Rsmp_4e202d8c . . . > failed > /lib/modules/2.2.14/net/tulip.o: insmod tulip failed > > > Does anyone have any other suggestions? I would appreciate it. The > only reason I am tring to do this is because the Netgear FA-310TX card > that I have comes up (during system boot) more or less broken and the > only thing I can find to fix it is a ifdown -a followed by a ifup -a. > > Thanks > Parrish M Myers > > ===== > ----------------------------------------------------------- > Academia is a little like child | Parrish M. Myers > rearing, it provides a chance at | The Wacked Jester > immortality without the stretch | parrishmm@earthlink.net > marks -- (unknown source) | > ----------------------------------------------------------- > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip > ========================================================================= Jos� A. Guzm�n jose@iteso.mx Servicios de Informaci�n, ITESO ========================================================================= From marco.flohrer@informatik.tu-chemnitz.de Tue, 30 May 2000 15:36:04 +0200 (MET DST) Date: Tue, 30 May 2000 15:36:04 +0200 (MET DST) From: Marco Flohrer marco.flohrer@informatik.tu-chemnitz.de Subject: [tulip] Cogent EM400 interrupt problem It seems that i actually can only use the first port of my multiport board. It is an Cogent EM400 (4 * 100MBit-only) on a ASUS P5A-B motherboard (Award BIOS). The BIOS gives every port another interrupt but tulip.c detects for all ports the same interrupt. The fitst port have in booth cases the same irq, so it runs. The following schows outputs from 'dmesg', 'cat /proc/pci', 'cat /proc/interrupts', 'cat /proc/ioports', tulipdiag an the result of a 'ping' to the other station connected via crossover cable on the second port. PS: i use kernel version 2.2.14 and it's included tulip.c eth2: Digital DS21140 Tulip rev 32 at 0xb800, 00:00:92:95:2A:C8, IRQ 11. eth2: EEPROM default media type Autosense. eth2: Index #0 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth2: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth3: Digital DS21140 Tulip rev 32 at 0xb400, EEPROM not present, 00:00:92:95:2A:C9, IRQ 11. eth3: Controller 1 of multiport board. eth3: EEPROM default media type Autosense. eth3: Index #0 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth3: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth4: Digital DS21140 Tulip rev 32 at 0xb000, EEPROM not present, 00:00:92:95:2A:CA, IRQ 11. eth4: Controller 2 of multiport board. eth4: EEPROM default media type Autosense. eth4: Index #0 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth4: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth5: Digital DS21140 Tulip rev 32 at 0xa800, EEPROM not present, 00:00:92:95:2A:CB, IRQ 11. eth5: Controller 3 of multiport board. eth5: EEPROM default media type Autosense. eth5: Index #0 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth5: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. PCI devices found: Bus 0, device 0, function 0: Host bridge: Acer Labs M1541 Aladdin V (rev 4). Slow devsel. Master Capable. Latency=64. Non-prefetchable 32 bit memory at 0xe0000000 [0xe0000000]. Bus 0, device 1, function 0: PCI bridge: Acer Labs M5243 AGP (rev 4). Slow devsel. Master Capable. Latency=64. Min Gnt=8. Bus 0, device 3, function 0: Bridge: Acer Labs M7101 PMU (rev 0). Medium devsel. Fast back-to-back capable. Bus 0, device 7, function 0: ISA bridge: Acer Labs M1533 Aladdin IV (rev 195). Medium devsel. Master Capable. No bursts. Bus 0, device 9, function 0: PCI bridge: DEC DC21050 (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. Min Gnt=4. Bus 0, device 10, function 0: Ethernet controller: DEC DC21041 (rev 33). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=32. I/O at 0x9800 [0x9801]. Non-prefetchable 32 bit memory at 0xdc800000 [0xdc800000]. Bus 0, device 11, function 0: Ethernet controller: DEC DC21041 (rev 33). Medium devsel. Fast back-to-back capable. IRQ 5. Master Capable. Latency=32. I/O at 0x9400 [0x9401]. Non-prefetchable 32 bit memory at 0xdc000000 [0xdc000000]. Bus 0, device 15, function 0: IDE interface: Acer Labs M5229 TXpro (rev 193). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. Min Gnt=2.Max Lat=4. I/O at 0x9000 [0x9001]. Bus 1, device 0, function 0: VGA compatible controller: Silicon Integrated Systems 3D-AGP 6326 VGA (rev 10). Medium devsel. Master Capable. Latency=64. Min Gnt=2. Prefetchable 32 bit memory at 0xe7800000 [0xe7800008]. Non-prefetchable 32 bit memory at 0xdf800000 [0xdf800000]. I/O at 0xd800 [0xd801]. Bus 2, device 4, function 0: Ethernet controller: DEC DC21140 (rev 32). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xb800 [0xb801]. Non-prefetchable 32 bit memory at 0xde800000 [0xde800000]. Bus 2, device 5, function 0: Ethernet controller: DEC DC21140 (rev 32). Medium devsel. Fast back-to-back capable. IRQ 12. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xb400 [0xb401]. Non-prefetchable 32 bit memory at 0xde000000 [0xde000000]. Bus 2, device 6, function 0: Ethernet controller: DEC DC21140 (rev 32). Medium devsel. Fast back-to-back capable. IRQ 5. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xb000 [0xb001]. Non-prefetchable 32 bit memory at 0xdd800000 [0xdd800000]. Bus 2, device 7, function 0: Ethernet controller: DEC DC21140 (rev 32). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xa800 [0xa801]. Non-prefetchable 32 bit memory at 0xdd000000 [0xdd000000]. CPU0 0: 342353 XT-PIC timer 1: 80 XT-PIC keyboard 2: 0 XT-PIC cascade 4: 4 XT-PIC serial 5: 41 XT-PIC eth1 7: 0 XT-PIC parport0 10: 28800 XT-PIC eth0 11: 44567 XT-PIC eth2 13: 1 XT-PIC fpu 14: 17206 XT-PIC ide0 15: 0 XT-PIC ide1 NMI: 0 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0290-0297 : lm78 02f8-02ff : serial(auto) 0376-0376 : ide1 0378-037a : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 9000-9007 : ide0 9008-900f : ide1 9400-947f : eth1 9800-987f : eth0 a800-a87f : eth5 b000-b07f : eth4 b400-b47f : eth3 b800-b87f : eth2 tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0x9800. Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 000021c4. Internal autonegotiation state is 'Ability detect'. Index #2: Found a Digital DC21041 Tulip adapter at 0x9400. Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 000050c8. Internal autonegotiation state is 'Negotiation complete'. Index #3: Found a Digital DS21140 Tulip adapter at 0xb800. Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 512. Index #4: Found a Digital DS21140 Tulip adapter at 0xb400. Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. WARNING: The EEPROM is missing or erased! Index #5: Found a Digital DS21140 Tulip adapter at 0xb000. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. WARNING: The EEPROM is missing or erased! Index #6: Found a Digital DS21140 Tulip adapter at 0xa800. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. WARNING: The EEPROM is missing or erased! PING 10.66.1.4 (10.66.1.4): 56 data bytes ping: sendto: Operation not permitted ping: wrote 10.66.1.4 64 chars, ret=-1 -- mailto: marco.flohrer@informatik.tu-chemnitz.de talk: mafl@diamond.csn.tu-chemnitz.de From alhaz@xmission.com Tue, 30 May 2000 08:41:58 -0600 Date: Tue, 30 May 2000 08:41:58 -0600 From: Eric Jorgensen alhaz@xmission.com Subject: [tulip] Cogent EM400 interrupt problem Marco Flohrer wrote: > > It seems that i actually can only use the first port of my multiport board. > It is an Cogent EM400 (4 * 100MBit-only) on a ASUS P5A-B motherboard > (Award BIOS). The BIOS gives every port another interrupt but tulip.c > detects for all ports the same interrupt. > The fitst port have in booth cases the same irq, so it runs. > The following schows outputs from 'dmesg', 'cat /proc/pci', > 'cat /proc/interrupts', 'cat /proc/ioports', tulipdiag an the result of a > 'ping' to the other station connected via crossover cable on the second > port. > > PS: i use kernel version 2.2.14 and it's included tulip.c (SNIP!) > PING 10.66.1.4 (10.66.1.4): 56 data bytes > ping: sendto: Operation not permitted > ping: wrote 10.66.1.4 64 chars, ret=-1 I have a Cogent 10mbps board that works in some systems and not in others - it's an issue of PCI bios. There's a page about it somewhere off the tulip page. With the 10mbps board, what I see in broken systems is that all link lights go on when the driver is loaded, and then go off when i plug in a cable, and the error is i believe "network unreachable". Doesn't work in a FIC PA-2006 but does work in an ABIT BP6, which i believe are both Award bios, the ABIT is just a lot newer and has an Intel BX chipset where the FIC has an older VIA chipset. *shrug*. FWIW, "operation not permitted" is the error I see when i try to do something that an ipchains rule DENY's. - Eric From marco.flohrer@informatik.tu-chemnitz.de Wed, 31 May 2000 03:08:32 +0200 (MET DST) Date: Wed, 31 May 2000 03:08:32 +0200 (MET DST) From: Marco Flohrer marco.flohrer@informatik.tu-chemnitz.de Subject: [tulip] Cogent EM400 interrupt problem On Tue, 30 May 2000, Eric Jorgensen wrote: > Marco Flohrer wrote: > > It seems that i actually can only use the first port of my multiport board. > > It is an Cogent EM400 (4 * 100MBit-only) on a ASUS P5A-B motherboard > > (Award BIOS). The BIOS gives every port another interrupt but tulip.c > > detects for all ports the same interrupt. > > The fitst port have in booth cases the same irq, so it runs. > > The following schows outputs from 'dmesg', 'cat /proc/pci', > > 'cat /proc/interrupts', 'cat /proc/ioports', tulipdiag an the result of a > > 'ping' to the other station connected via crossover cable on the second > > port. > > > > PS: i use kernel version 2.2.14 and it's included tulip.c > (SNIP!) > > PING 10.66.1.4 (10.66.1.4): 56 data bytes > > ping: sendto: Operation not permitted > > ping: wrote 10.66.1.4 64 chars, ret=-1 > > FWIW, "operation not permitted" is the error I see when i try to do > something that an ipchains rule DENY's. Argh! I use this host also as a firewall. Default policy is DENY an i had no rule to allow anything for eth3, because i had only eth0-2 before. Thanks, that was ist! -- Now STRONGARMed and dangerous! No RISC, no fun!:) mailto: marco.flohrer@informatik.tu-chemnitz.de talk: mafl@diamond.csn.tu-chemnitz.de