From Gimmas@aol.com Tue Jan 1 16:49:00 2002 From: Gimmas@aol.com (Gimmas@aol.com) Date: Tue Jan 1 16:49:00 2002 Subject: [tulip] FA310TX card and Redhat 7.0 Message-ID: <3f.44c17cc.296388c1@aol.com> --part1_3f.44c17cc.296388c1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I made a clean install of Redhat 7.0 on an Intel based system. After having problems getting a Netgear FA310TX network card to work I found the Scyld site and found the precompiled RPM which I tried to install. I get the following error for many of the individual drivers "file /lib/modules/2.2.16-22/net/tulip.o from install of netdriver-2.1-2 conflicts with file from package kernel-2.2.16-22" . I have tried it as an upgrade and install, also if I tell it to go ahead and install anyway the package install still fails. Is there something I need to do before installing the RPM? Has it worked for anyone? Thanks Mark --part1_3f.44c17cc.296388c1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I made a clean install of Redhat 7.0 on an Intel based system. After having problems getting a Netgear FA310TX network card to work I found the Scyld site and found the precompiled RPM which I tried to install. I get the following error for many of the individual drivers  "file /lib/modules/2.2.16-22/net/tulip.o from install of netdriver-2.1-2 conflicts with file from package kernel-2.2.16-22" .     I have tried it as an upgrade and install, also if I tell it to go
ahead and install anyway the package install still fails. Is there something I need to do before installing the RPM? Has it worked for anyone?
Thanks
Mark


--part1_3f.44c17cc.296388c1_boundary-- From Will@compusa.com Wed Jan 2 13:22:02 2002 From: Will@compusa.com (White, Will) Date: Wed Jan 2 13:22:02 2002 Subject: [tulip] Redhat 7.2 Kingston NIC cannot ping server until I initiate an ou tgoing ping Message-ID: <317BAF8C2046D511BF0600E0293632E5C387@foxhound.compusa.com> I have Redhat 7.2 loaded in server mode with a Kingston NIC with an autodetected tulip driver. I'm currently plugged into a Cisco 1924 switch. The problem is that I cannot get to the server (ping, SSH, Mail, Web, anything) until I initiate a ping from the server to outside my subnet. I have an hourly cron set up to ping out just so I can access my box remotely. I've set the duplex to half in the modules.conf, but it didn't help (thought maybe it was an autonegotiation hiccup). Ipchains is currently disabled, so it isn't a firewall issue. apmd and all power saver features (including wake on lan) in the BIOS are disabled as well. Has anyone else had this problem or know the solution? thanks... From becker@scyld.com Wed Jan 2 16:03:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jan 2 16:03:01 2002 Subject: [tulip] Redhat 7.2 Kingston NIC cannot ping server until I initiate an ou tgoing ping In-Reply-To: <317BAF8C2046D511BF0600E0293632E5C387@foxhound.compusa.com> Message-ID: On Wed, 2 Jan 2002, White, Will wrote: > I have Redhat 7.2 loaded in server mode with a Kingston NIC with an > autodetected tulip driver. I'm currently plugged into a Cisco 1924 switch. > The problem is that I cannot get to the server (ping, SSH, Mail, Web, > anything) until I initiate a ping from the server to outside my > subnet. What is the driver detection message, including version number? ("Kingston NIC" is not specific -- there are many.) > I have an hourly cron set up to ping out just so I can access my box > remotely. I've set the duplex to half in the modules.conf, but it > didn't help (thought maybe it was an autonegotiation hiccup). Have you tried a current driver: http://www.scyld.com/network/tulip.html ftp://www.scyld.com/pub/network/tulip.c Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From strombrg@nis.acs.uci.edu Wed Jan 2 19:32:04 2002 From: strombrg@nis.acs.uci.edu (Dan Stromberg) Date: Wed Jan 2 19:32:04 2002 Subject: [tulip] Redhat 7.2 Kingston NIC cannot ping server until I initiate an ou tgoing ping In-Reply-To: <317BAF8C2046D511BF0600E0293632E5C387@foxhound.compusa.com>; from Will@compusa.com on Wed, Jan 02, 2002 at 12:18:34PM -0600 References: <317BAF8C2046D511BF0600E0293632E5C387@foxhound.compusa.com> Message-ID: <20020102162517.F25819@seki.acs.uci.edu> --JcvBIhDvR6w3jUPA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2002 at 12:18:34PM -0600, White, Will wrote: > I have Redhat 7.2 loaded in server mode with a Kingston NIC with an > autodetected tulip driver. I'm currently plugged into a Cisco 1924 switch. > The problem is that I cannot get to the server (ping, SSH, Mail, Web, > anything) until I initiate a ping from the server to outside my subnet. I > have an hourly cron set up to ping out just so I can access my box remote= ly. > I've set the duplex to half in the modules.conf, but it didn't help (thou= ght > maybe it was an autonegotiation hiccup). Ipchains is currently disabled, = so > it isn't a firewall issue. apmd and all power saver features (including w= ake > on lan) in the BIOS are disabled as well. Has anyone else had this problem > or know the solution? thanks...=20 I've seen the same problem on a sun. We're attributing it to a broken cisco switch, though I'm told that this isn't the only brand of switch with the problem. --=20 Dan Stromberg UCI/NACS/DCS --JcvBIhDvR6w3jUPA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8M6Tso0feVm00f/8RAgldAJ0QNPHZ6jjzOGT8nyx1IiCEGnzzLgCfX9EW JM2tp+MWiT0ncpojXEV/WyI= =T+7V -----END PGP SIGNATURE----- --JcvBIhDvR6w3jUPA-- From samir_purohit@yahoo.com Sat Jan 5 14:55:02 2002 From: samir_purohit@yahoo.com (samir Purohit) Date: Sat Jan 5 14:55:02 2002 Subject: [tulip] RH7.1(2.4.2.2) on Presario Laptop Message-ID: <20020105195451.21841.qmail@web20506.mail.yahoo.com> Hi !! This question may probably be best answered by Donald Becker. I tried installing tulip driver on Compaq Presario 17XL3 laptop having RedHat Linux version 7.1 (kernel 2.4.2.2) but I am unable to get 'eth0' activated. I surfed through a lot of messages in mailing-list and followed the steps mentioned by Kent Hunt and Donald Becker for installing tulip and pci-scan files. Since the compilation was giving warnings regarding APMs, I also modified 'if defined CONFIG_APM' with 'if defined CONFIG_APM && LINUX_VERSION_CODE < 0x20400', which resulted in compilation without any warnings, but then insmod pci-scan and tulip both give unresolved symbol errors. Also since I modified module.dep file with the apprpriate entries, whenever I reboot, it throws '**Unresolved Symbols in tulip.o' error along with 'delaying eth0: failed' message. I have a Compaq 10_100 MiniPCI ethernet card which works fine with Windows. Can anyone help me in this please? Thanx in anticipation.. Cheers, Sam. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From pasch@netzGeneration.com Sat Jan 5 17:44:01 2002 From: pasch@netzGeneration.com (Thomas Pasch) Date: Sat Jan 5 17:44:01 2002 Subject: [tulip] RE: LinkPRO TL-5320cb (Was: W-LINX LinxPRO Ethernet) Message-ID: <002201c1963b$048b9d20$0300a8c0@frosch> This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C19643.617BC0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, this is a continuation to the December Thread by Micheal Thaler and Ronald Becker. On a SuSE-7.1 with pcmcia-3.1.22 I encounter the same problems describe by Michael. Then I switch to 3.1.31. It now works. I'm still using the 'tulip.c:v0.91g-ppc 7/16/99' driver. Compiling v0.93 seems difficult to me. I've enclosed many details for the curious. Have fun! Thomas Identification of card: > cardctl ident Socket 0: product info: "CardBus", "Fast Ethernet", "V1.0", "" manfid: 0x13d1, 0xab02 function: 6 (network) PCI id: 0x13d1, 0xab08 Socket 1: no product info available Identification of chip be the kernel messages: > dmesg [...] Linux PCMCIA Card Services 3.1.31 kernel build: 2.4.0-4GB #1 Mon Jan 22 16:42:16 GMT 2001 options: [pci] [cardbus] [apm] Intel ISA/PCI/CardBus PCIC probe: PCI: Found IRQ 15 for device 00:11.0 PCI: Found IRQ 11 for device 00:11.1 PCI: The same IRQ used for device 00:10.0 TI 1131 rev 01 PCI-to-CardBus at slot 00:11, mem 0x7fffe000 host opts [0]: [ring] [pci + serial irq] [pci irq 15] [lat 66/176] [bus 1/1] host opts [1]: [ring] [pci + serial irq] [pci irq 11] [lat 66/176] [bus 2/2] ISA irqs (scanned) = 3,4,5,7,9,10 PCI status changes cs: cb_alloc(bus 1): vendor 0x13d1, device 0xab08 cs: cb_config(bus 1) cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x220-0x22f 0x250-0x257 0 cs: IO port probe 0x0230-0x024f: clean. cs: IO port probe 0x0258-0x032f: clean. cs: IO port probe 0x0338-0x0377: clean. cs: IO port probe 0x0380-0x0387: clean. cs: IO port probe 0x0390-0x03bf: clean. cs: IO port probe 0x03e0-0x0407: clean. cs: IO port probe 0x0410-0x047f: clean. cs: IO port probe 0x0490-0x04cf: clean. cs: IO port probe 0x04d8-0x04ff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0a00-0x0aff: clean. cs: IO port probe 0x0c00-0x0cff: clean. fn 0 bar 1: io 0x800-0x8ff fn 0 bar 2: mem 0x60060000-0x600603ff fn 0 rom: mem 0x60040000-0x6005ffff irq 15 cs: cb_enable(bus 1) bridge io map 0 (flags 0x21): 0x800-0x8ff bridge mem map 0 (flags 0x1): 0x60040000-0x60060fff tulip_attach(device 01:00.0) tulip.c:v0.91g-ppc 7/16/99 becker@scyld.com (modified by danilo@cs.uni-magdeburgeth0: ADMtek Centaur-C rev 17 at 0x800, 00:E0:98:21:31:F8, IRQ 15. PCI: Found IRQ 11 for device 00:10.0 PCI: The same IRQ used for device 00:11.1 The tulip-diag programm has some problems: > ./tulip-diag tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Unable to find a recognized card in /proc/pci. If there is a card in the machine, explicitly set the I/O port address using '-p -t ' Use '-t -1' to see the valid chip types. But it will work... > ./tulip-diag -p 0x800 -t 15 tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Assuming a ADMtek AL985 Centaur-C adapter at 0x800. Comet duplex is reported in the MII status registers. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 256. Comet MAC address registers 2198e000 fffff831 Comet multicast filter 8000000000000000. 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. > ./tulip-diag -p 0x800 -t 15 -e tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Assuming a ADMtek AL985 Centaur-C adapter at 0x800. Comet duplex is reported in the MII status registers. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 256. Comet MAC address registers 2198e000 fffff831 Comet multicast filter 8000000000000000. EEPROM 256 words, 8 address bits. Ethernet MAC Station Address 00:e0:98:21:31:f8. Default connection type 'Autosense'. PCI IDs Vendor 13d1 Device ab08 Subsystem 13d1 ab08 PCI min_grant 255 max_latency 255. CSR18 power-up setting 0x80cc****. > ./tulip-diag -p 0x800 -t 15 -a tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Assuming a ADMtek AL985 Centaur-C adapter at 0x800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. ADMtek AL985 Centaur-C chip registers at 0x800: 0x00: fff98000 ffffffff ffffffff 00b08010 00b08210 fc664010 ff976117 ffffebff Comet duplex is reported in the MII status registers. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 256. Comet MAC address registers 2198e000 fffff831 Comet multicast filter 8000000000000000. trying to compile tulip.c as tulip_cb.c in pcmcia-cs-3.1.32/clients: make[1]: Entering directory `/root/linkpro/pcmcia-cs-3.1.31/clients' cc -MD -c -O2 -I../include -I/usr/src/linux/include -D__KERNEL__ -DEXPORT_SYMTAB -DMODULE -DCARDBUS tulip_cb.c tulip_cb.c:162: pci-scan.h: No such file or directory tulip_cb.c:163: kern_compat.h: No such file or directory make[1]: *** [tulip_cb.o] Error 1 make[1]: Leaving directory `/root/linkpro/pcmcia-cs-3.1.31/clients' make: *** [all] Error 2 ------=_NextPart_000_001F_01C19643.617BC0C0 Content-Type: text/x-vcard; name="Thomas Pasch.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Thomas Pasch.vcf" BEGIN:VCARD VERSION:2.1 N:Pasch;Thomas FN:Thomas Pasch TEL;HOME;VOICE:0531 7075953 TEL;HOME;FAX:069 791260246 ADR;HOME:;;;Braunschweig LABEL;HOME:Braunschweig URL;HOME:http://www.netzGeneration.com EMAIL;PREF;INTERNET:pasch@netzGeneration.com REV:20020105T224748Z END:VCARD ------=_NextPart_000_001F_01C19643.617BC0C0-- From gby@kagoor.com Sun Jan 6 05:02:01 2002 From: gby@kagoor.com (Gilad Ben-Yossef) Date: Sun Jan 6 05:02:01 2002 Subject: [tulip] Fixed 100BaseT problems? Message-ID: Hi there, I seem to be having a problem as follows: The card (see *-diag output at end of message) is connected to a Catalyst3500 switch. When both ends auto negotiate I get full duplex 100 mbps as expected. When the cards are set to fixed 100 mbps full duplex however I'm starting to get loses that aren't there before. There are two ports on this cards, and the Linux bridging code is used to bridge between them (kernel version 2.2.16 with the new bridge from 2.4.x applied as patch). However, the losses seems to occur on the card, and not in the bridging code. The specific card in question is custom made (includes fail safe hardware), so make and model won't say much, but the very same thing happens with a D-Link 4 ports (for the card) and a Shomiti Surveyor (for the other end). Any help or pointer to information will be highly apreciated. If this is some sort of FAQ, I apologise, but I couldn't locate the answer. Any additional needed info will be happily supplied. Please reply to 'gby@kagoor.com; (the sender), as I am not a regular subscriber to the mailing list. Many Thanks! Gilad I load the driver with: insmod tulip.o options=0x3 full_duplex=1 tulip-diag said: tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xdc00. 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. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xd880. 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. 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. mii-diag said: Basic registers of MII PHY #0: 2100 780d 0013 78e2 01e1 0000 0004 2001. Basic mode control register 0x2100: Auto-negotiation disabled, with Speed fixed at 100 mbps, full-duplex. You have link beat, and everything is working OK. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. -- Gilad Ben-Yossef Tel: +972(9)9717330 | Fax: +972(9)9717334 | Cel: +972(54)756701 Kagoor Networks ltd | http://www.kagoor.com | From swmike@swm.pp.se Sun Jan 6 07:55:00 2002 From: swmike@swm.pp.se (Mikael Abrahamsson) Date: Sun Jan 6 07:55:00 2002 Subject: [tulip] Fixed 100BaseT problems? In-Reply-To: Message-ID: On Sun, 6 Jan 2002, Gilad Ben-Yossef wrote: > The card (see *-diag output at end of message) is connected to a > Catalyst3500 switch. When both ends auto negotiate I get full duplex > 100 mbps as expected. When the cards are set to fixed 100 mbps full > duplex however I'm starting to get loses that aren't there before. Put "speed 100" and "duplex full" on the cisco switch port, and I think you'll be better off. Let autoneg be, it works in 99% of the cases in my experience. Fiddling with fixed speeds is more trouble and you have to know what you're doing. If you turn off autoneg on one party, the other party will autoneg to half duplex. If you turn off autoneg, you have to force both ends to the same speed/duplex or you'll be in trouble. -- Mikael Abrahamsson email: swmike@swm.pp.se From gby@kagoor.com Sun Jan 6 08:11:01 2002 From: gby@kagoor.com (Gilad Ben-Yossef) Date: Sun Jan 6 08:11:01 2002 Subject: [tulip] Fixed 100BaseT problems? In-Reply-To: Message-ID: > On Sun, 6 Jan 2002, Gilad Ben-Yossef wrote: > > > The card (see *-diag output at end of message) is connected to a > > Catalyst3500 switch. When both ends auto negotiate I get full duplex > > 100 mbps as expected. When the cards are set to fixed 100 mbps full > > duplex however I'm starting to get loses that aren't there before. > > Put "speed 100" and "duplex full" on the cisco switch port, and I think > you'll be better off. The switch is configured as you specified. Sorry for not making this clear. > Let autoneg be, it works in 99% of the cases in my experience. Fiddling > with fixed speeds is more trouble and you have to know what you're doing. I would be very happy if I could. Unfortunately, we have a customer that requires a fixed setting. > If you turn off autoneg on one party, the other party will > autoneg to half > duplex. If you turn off autoneg, you have to force both ends to the same > speed/duplex or you'll be in trouble. I understand this. The case here is that both parties are set to a fixed setting of 100 mps and full-duplex. The setting does work but loss of 2% occurs. In the very same setup with autonet (both sides) there is no less. Traffic is 6,000 pps. Most of them are 64byte long (VoIP traffic). I hope this makes the situation more clear. Thanks! Gilad. -- Gilad Ben-Yossef Tel: +972(9)9717330 | Fax: +972(9)9717334 | Cel: +972(54)756701 Kagoor Networks ltd | http://www.kagoor.com | From swmike@swm.pp.se Sun Jan 6 08:32:01 2002 From: swmike@swm.pp.se (Mikael Abrahamsson) Date: Sun Jan 6 08:32:01 2002 Subject: [tulip] Fixed 100BaseT problems? In-Reply-To: Message-ID: On Sun, 6 Jan 2002, Gilad Ben-Yossef wrote: > I understand this. The case here is that both parties are set to a > fixed setting of 100 mps and full-duplex. The setting does work but > loss of 2% occurs. In the very same setup with autonet (both sides) > there is no less. Traffic is 6,000 pps. Most of them are 64byte long > (VoIP traffic). Post a "show int fasteth1/x" from the switch. Clear counters first, then run some tests with fixed speed/duplex. 2% loss with 6000pps (that's 4-5 megabits of traffic if my math is correct) sounds like it could be duplex problems. Show int reveals that pretty quickly. At that speed it sounds like you could try half duplex as well without any major problems. If nothing else, for testing purposes. Personally I make a habit of not trying to fix speed, I always autoneg. Trying to lock the speed always gives me more problem that autoneg ever has. -- Mikael Abrahamsson email: swmike@swm.pp.se From samir_purohit@yahoo.com Sun Jan 6 20:51:01 2002 From: samir_purohit@yahoo.com (samir Purohit) Date: Sun Jan 6 20:51:01 2002 Subject: [tulip] RH7.1 on Presario 1700T laptop Message-ID: <20020107015004.53479.qmail@web20508.mail.yahoo.com> Hi !! Folks...I did a bit more research and I managed to get the latest tulip.c and pci-scan.c compiled without any error messages. But insmod command throws a lot of unresolved symbols errors. e.g. insmod pci-scan.o gives following output: pci-scan.o: unresolved symbol pci_write_config_byte pci-scan.o: unresolved symbol kmalloc pci-scan.o: unresolved symbol pci_find_class pci-scan.o: unresolved symbol __check_region pci-scan.o: unresolved symbol pci_read_config_byte pci-scan.o: unresolved symbol pci_read_config_dword pci-scan.o: unresolved symbol __ioremap pci-scan.o: unresolved symbol pci_read_config_word pci-scan.o: unresolved symbol kfree pci-scan.o: unresolved symbol pci_set_master pci-scan.o: unresolved symbol pci_write_config_dword pci-scan.o: unresolved symbol pci_write_config_word pci-scan.o: unresolved symbol printk pci-scan.o: unresolved symbol ioport_resource This still causes 'initializing eth0: delaying..... failed' error. The output of tulip-diag is as follows: [root@localhost tulip-0.92wax]# ./tulip-diag -aem tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Conexant LANfinity chip registers at 0x1400: 0x00: fff80000 ffffffff ffffffff 00000000 00000000 f4008800 e00c0040 7bfe0000 0x40: fffe0000 fff080e8 fffe0000 fffe0000 ffffffff ffffffff ffffffff f7f9fec8 Extended registers: 80: cc008800 cbfe0000 f0000018 00000000 ffffffff 00000000 00000000 00000000 a0: ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 e0: 00000000 00000000 00000000 00000000 ffffffff 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 'Stopped'. The transmit threshold is 128. Interrupt sources are pending! CSR5 is f4008800. Timer expired indication. EEPROM 256 words, 8 address bits. Conexant EEPROM format is undocumented. MII PHY found at address 1, status 0x7809. MII PHY found at address 0, status 0x7809. MII PHY #1 transceiver registers: 1000 7809 0022 1720 01e1 0000 0004 2001 1000 7809 0022 1720 01e1 0000 0004 2001 1000 7809 0022 1720 01e1 0000 0004 2001 0000 0000 0000 0000 01e1 2001 0000 8c00. MII PHY #0 transceiver registers: 1000 7809 0022 1720 01e1 0000 0004 2001 1000 7809 0022 1720 01e1 0000 0004 2001 1000 7809 0022 1720 01e1 0000 0004 2001 0000 0000 0000 0000 01e1 2001 0000 8c00. Can anybody suggest if I have missed anything? Just to refresh, I have Compaq Presario 17XL3 with RedHat Linux 7.1 (kernel 2.4.2.2) with the Conexant LanFinity ethernet card. Thanx.. Cheers, Sam. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From d.bertini@gsi.de Mon Jan 7 08:31:01 2002 From: d.bertini@gsi.de (Denis Bertini) Date: Mon Jan 7 08:31:01 2002 Subject: [tulip] problem with Accton en2242 Message-ID: <3C39A29A.68B73CDF@gsi.de> Hi All, I have a new laptop GERICOM working with the newest SUSE linux 7.2 (kernel 2.4.10) The network card is an Accton EN2242 minipci (on -mother board chip) doesn't work. Should i need to modify the tulip driver that come with the new SUSE distribution ( i looked inside and the last modification from D.Becker is included to support this card). Any Hints? Thanks in advance, Denis BERTINI GSI-Darmstadt From Joerg.Dieter.Friedrich@uni-konstanz.de Mon Jan 7 12:07:02 2002 From: Joerg.Dieter.Friedrich@uni-konstanz.de (Joerg Friedrich) Date: Mon Jan 7 12:07:02 2002 Subject: [tulip] problem with Accton en2242 In-Reply-To: <3C39A29A.68B73CDF@gsi.de> References: <3C39A29A.68B73CDF@gsi.de> Message-ID: <20020107165910.GA15360@mail.terrania.city> Denis Bertini schrieb am Montag, 07. Januar 2002 um 14:28:58 +0100: > Hi All, > > I have a new laptop GERICOM working with the newest SUSE linux 7.2 > (kernel 2.4.10) > The network card is an Accton EN2242 minipci (on -mother board chip) > doesn't > work. Should i need to modify the tulip driver that come with the new > SUSE distribution > ( i looked inside and the last modification from D.Becker is included > to support > this card). > Any Hints? Hi Denis! Your problem known, I've got the same. I mailed this list also, but there are no hints for gericom laptops. The reason of this problem is that the bios leaves irq-assignments to the os and there is no bios-setting to change (until gericom provides an bios-update) But these people say that they only support Windows. I do not know what to do. As far as I can see it's no problem of the tulip-driver, but a problem of PCI-Driver, but I do not have the ability to track down and fix it. -- Heute ist nicht alle Tage, ich komm' wieder, keine Frage!!! Joerg Why on earth do people buy old bottles of wine when they can get a fresh one for a quarter of the price? From krirkcht@hotmail.com Tue Jan 8 04:37:01 2002 From: krirkcht@hotmail.com (krirkchai Thanon) Date: Tue Jan 8 04:37:01 2002 Subject: [tulip] (no subject) Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C19862.BC860040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear sir or madam, I got a problem to installed linksys LNE100TX on Linux redhat 7.1 . How = can I do it? Regards, Krirkchai Thanon Senior Engineer Combudia Air Traffic Services Co,Ltd. Email: krirkcht@hotmail.com ------=_NextPart_000_001D_01C19862.BC860040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear sir or madam,
I got a problem to installed linksys = LNE100TX on=20 Linux redhat 7.1 . How can I do it?
Regards,
Krirkchai Thanon
Senior Engineer
Combudia Air Traffic Services = Co,Ltd.
Email: krirkcht@hotmail.com
 
 
------=_NextPart_000_001D_01C19862.BC860040-- From steve@extex.com Tue Jan 8 12:46:02 2002 From: steve@extex.com (Steve Keith) Date: Tue Jan 8 12:46:02 2002 Subject: [tulip] RH 7.2/tulip/Netgear FA310TX Message-ID: <5.0.2.1.0.20020108103606.0232edc0@mailserver.marketal.com> I've searched Redhat, linuxdoc.org and a few months back through the archives, but I haven't found a solution to my problem. Hardware: IBM PC 365 w/dual PPro processors & 192M RAM Linksys 100Base-TX Switch Netgear FA310TX Installation detected the card and loaded the Tulip driver included with RH 7.2. For about ten minutes it works perfectly. For another ten minutes, it slows down significantly. After 20 minutes total uptime, the network card performance slows to a crawl and stays there until a reboot. Telnet/ssh connections lag and file transfers via samba are very very slow. I downloaded, complied and installed the latest tulip drivers. The results were the same. I tried a Netgear FA311 (natsemi drivers) with the exact same results. When I use an ISA 3Com 3C509 10Base-T card, things work as expected. Any thoughts? Thanks, Steve --- Steve Keith Engineering Manager http://www.extex.com EXTEX, Ltd. 5950 S. Sossaman Rd. Mesa, AZ 85212 (480) 988-2000 x 2007 (480) 988-1012 fax From Holger@Jakobs.com Wed Jan 9 12:27:01 2002 From: Holger@Jakobs.com (Holger@Jakobs.com) Date: Wed Jan 9 12:27:01 2002 Subject: [tulip] Help: Accton EN2242 in 1st Supersonic M6T notebook Message-ID: <3C3C8BCA.12958.397C47@localhost> Hi everybody, I have been searching for a way of using the builtin 10/100 Mbit/s network adapter, obviously an Accton EN2242 in my 1st Supersonic M6T notebook by www.gericom.com After finding out that there is a "tulip" driver that might be able to make use of it, I tried to make changes to the module, file tulip_core.c and also found hints that some driver called tulip.c should be changed. None of them worked. Some nice people tried to help by telling me to change settings in the BIOS, but unfortunately the BIOS in the machine does not have these "advanced" settings like PnP-OS or the like. Trying to insert a successfully compiled pci-scan.o module gives lots of unresolved symbols like "pci_write_config_byte", "pci_find_class", "kmalloc" and the like, so working according to {HYPERLINK "mailto:tulip@scyld.com?Subject=Re:%20[tulip]%20Problems%20compiling%20the%20tulip%20driver&In-Reply-To= Greetings, I'm having a problem compiling the tulip module drivers into my 2.2.19 kernel. I have RedHat 7.1 installed and am downgrading the kernel to 2.2.19. Per the instructions, I downloaded the individual driver file (tulip.c), pci-scan.c, pci-scan.h, and kern_compat.h and placed them in my kernel drivers/net directory and recompiled without any errors. BTW, I placed tulip.o and pci-scan.o in the modules directory (/lib/modules/2.2.19/net). The problem I'm having is upon trying to load the module (insmod). It's giving some unresolved symbol errors, as shown here: =========================================================================== [root@freedom net]# insmod -v tulip.o Using tulip.o Symbol version prefix 'smp_' tulip.o: unresolved symbol pci_drv_unregister tulip.o: unresolved symbol pci_drv_register =========================================================================== These are found in pci-scan.c... I don't have a whole lot of experience with modules, but I also tried: =========================================================================== [root@freedom net]# insmod -v pci-scan.o Using pci-scan.o Symbol version prefix 'smp_' pci-scan.o: kernel-module version mismatch pci-scan.o was compiled for kernel version 2.2.16-22 while this kernel is version 2.2.19. [root@freedom net]# insmod -f -v pci-scan.o Using pci-scan.o Symbol version prefix 'smp_' Warning: kernel-module version mismatch pci-scan.o was compiled for kernel version 2.2.16-22 while this kernel is version 2.2.19 pci-scan.o: unresolved symbol __ioremap_R9eac042a pci-scan.o: unresolved symbol pci_find_class_R6c460806 pci-scan.o: unresolved symbol pci_write_config_word_Rd9cc3b03 pci-scan.o: unresolved symbol pci_write_config_dword_Rf0fbd200 pci-scan.o: unresolved symbol pci_read_config_dword_R2ca7e89f pci-scan.o: unresolved symbol pci_read_config_byte_Re5ceea13 pci-scan.o: unresolved symbol pci_write_config_byte_Re84d5397 pci-scan.o: unresolved symbol check_region_R522f4d72 pci-scan.o: unresolved symbol pci_set_master_R040f6432 pci-scan.o: unresolved symbol printk_R1b7d4074 pci-scan.o: unresolved symbol pci_read_config_word_R8764d15f =========================================================================== I did notice the report about the kernel version above, but that shouldn't have any affect on trying to load the module, right? I also tried compiling the tulip drivers without having it load as a module (monolithically) and it still doesn't work. FYI - The tulip module drivers with the 2.4.2-2 kernel that comes with RH 7.1 works just fine. Any ideas??? Thanks in advance for your help! --- Gregg Graubins Whitewater Technologies, Inc. (PGP key available) From becker@scyld.com Thu Jan 10 09:39:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jan 10 09:39:01 2002 Subject: [tulip] tulip v0.93 (11/7/01) problems for DS21140 quad card under RH 2.2.19 In-Reply-To: Message-ID: On Wed, 9 Jan 2002, Gregg Graubins wrote: > [root@freedom net]# insmod -v pci-scan.o > Using pci-scan.o > Symbol version prefix 'smp_' > pci-scan.o: kernel-module version mismatch > pci-scan.o was compiled for kernel version 2.2.16-22 > while this kernel is version 2.2.19. .. > I did notice the report about the kernel version above, but that shouldn't > have any affect on trying to load the module, right? That's the problem -- symbol mismatches are caused by compiling with the wrong kernel header files. If you have modversions enabled, you must use exactly the header files for your specific kernel. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jmichael@msn.fullfeed.com Fri Jan 11 23:21:00 2002 From: jmichael@msn.fullfeed.com (Justin C . Michael) Date: Fri Jan 11 23:21:00 2002 Subject: [tulip] problem with tulip on 2.4.16 and 2.4.17 ? Message-ID: <20020111222048.B4978@condor.msn.fullfeed.com> hi, I am having a problem with tcp throughput using the tulip driver. Others have expressed similar problems with TCP performance over tulip on 2.4.16. The problem shows itself to me when there is latency between the two systems. I have 90 ms latency between two systems and tcp throughput is about .45 mbps (using a tcp test tool). UDP performance is about 88 mbps. A thread in mlist.linux.kernel says the problem is with the tulip driver that shipped with 2.4.16. Please see as a reference: http://groups.google.com/groups?hl=en&threadm=linux.kernel.87d71pl0fm.fsf%40cbgb.rudedog.org&rnum=1&prev=/groups%3Fq%3Dtulip%2B2.4.16%2B2.4.14%26hl%3Den%26selm%3Dlinux.kernel.87d71pl0fm.fsf%2540cbgb.rudedog.org%26rnum%3D1 My environment is linux 2.4.16/2.4.17 with dlink 570-tx. It is connected to a catalyst 3500xl switch set at full duplex 100 meg while the card is set to autonegotiate. Is this problem confirmed or still in doubt? Can I help troubleshoot? Thanks! Justin From jdparker225@home.com Sun Jan 13 02:05:01 2002 From: jdparker225@home.com (Jim Parker) Date: Sun Jan 13 02:05:01 2002 Subject: [tulip] Build failing Message-ID: <3C4131BC.C11FFBB7@home.com> I'm trying to get my Linksys LNE100TX (Version 4) working in Red Hat 7.0 (2.2.19-7.0.10 Kernel) but it isn't working. These are the instructions from the web page (http://www.scyld.com/network/updates.html): ----------------Quote from web site -------------------------------------- Use the following commands to install and test the driver pack: # Transfer the Scyld PCI Netdriver package # Perhaps use ncftpget ftp://ftp.scyld.com/pub/network/netdrivers-3.0-1.src.rpm rpm -i ftp://ftp.scyld.com/pub/network/netdrivers-3.0-1.src.rpm # Build the binary version for your kernel cd /usr/src/{redhat,TurboLinux,packages}/ rpm -bb SPECS/netdriver*.spec # Now install it your newly built package. rpm -i --force RPMS/i386/netdrivers-3.0-1.i386.rpm The --force option is needed because the new drivers may conflict with the existing drivers installed by the kernel package. If this occurs you will see a warning message for each driver that has been updated. ---------------end of quote from web site ---------------------------------- The problem comes where I do "rpm -bb SPECS/netdrive*.spec". I get a ton of compiler errors. All seem to be one or the other of these: 1. `PAGE_OFFSET_RAW' undeclared 2. dereferencing pointer to incomplete type PAGE_OFFSET_RAW is defined in /usr/src/linux/include/asm/page_offset.h if any one of the following are defined: CONFIG_1GB, CONFIG_2GB or CONFIG_3GB. It appears that none of these are defined. I modified page_offset.h to provide a default definition for PAGE_OFFSET_RAW and this error message went away. However, in all likelihood I'm not providing a valid value for PAGE_OFFSET_RAW. So what the heck is CONFIG_*GB? What causes one of them to be defined? The "dereferencing pointer to incomplete type" errors are in pci-skeleton.c which is a file that came with the src.rpm. This is the first module compiled. My guess is that the build quit after these errors and didn't attempt to build any others. Any hints as to what is going wrong here and how to fix it? Thanks Jim. From dani-post@roisman.com Mon Jan 14 14:53:01 2002 From: dani-post@roisman.com (Dani Roisman) Date: Mon Jan 14 14:53:01 2002 Subject: [tulip] Re: problem with tulip card ceasing to function - requires ifdown/ifup to fix Message-ID: <20020114115247.A4687@inet1.roisman.com> ... following up my problems from 11/2001 .... We had a couple recurrances of the problem - where one interface on a DLINK DFE-570TX hangs, and requires an ifdown eth0 ; ifup eth0 to get going again. This time, I was able to get on and run some tulip-diag's before bringing up the interface. I know that Donlad B. wanted to see these. First the detection messages (FYI, since I'm only using eth0 and eth1, I've cut out messages for the other 2 interfaces to keep this email a bit shorter). I'll take suggestions, including what I should run next time to offer better troubleshooting information. Thank you! from dmesg: eth0: Digital DS21143-xD Tulip rev 65 at 0xc800, 00:80:C8:B9:98:4D, IRQ 12. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: MII transceiver #1 config 3100 status 7869 advertising 01e1. eth1: Digital DS21143-xD Tulip rev 65 at 0xc400, 00:80:C8:B9:98:4E, IRQ 5. 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 3100 status 7869 advertising 01e1. tulip.c:v0.92t 1/15/2001 Written by Donald Becker http://www.scyld.com/network/tulip.html # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:80:C8:B9:98:4D inet addr:WW.XX.YY.11 Bcast:WW.XX.YY.15 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2147483647 errors:0 dropped:94727 overruns:0 frame:0 TX packets:2147483647 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:12 Base address:0xc800 # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:80:C8:B9:98:4E inet addr:WW.XX.YY.1 Bcast:WW.XX.YY.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2147483647 errors:0 dropped:3 overruns:0 frame:0 TX packets:2147483647 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 Base address:0xc400 # tulip-diag -aa tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21143 Tulip chip registers at 0xc800: 0x00: f8a08000 ffffffff ffffffff 07fee800 07feea00 f0680000 b20e2202 fbfffbff Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21143 Tulip chip registers at 0xc400: 0x00: f8a08000 ffffffff ffffffff 07fee000 07fee200 f0660000 b20e6202 fbfffbff 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 256. The NWay status register is 000000c6. # tulip-diag -mm tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. MII PHY found at address 1, status 0x786d. MII PHY #1 transceiver registers: 1100 786d 2000 5c10 01e1 41e1 0007 2801 0000 0000 0000 0000 0000 0000 0000 0000 0a25 0000 0000 0000 0000 0000 0020 0000 0080 0001 00a3 0100 0006 0f00 0000 0000. Basic mode control register 0x1100: Auto-negotiation enabled. Basic mode status register 0x786d ... 786d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 08:00:17:--:--:--, model 1 rev. 0. 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 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. 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 256. The NWay status register is 000000c6. MII PHY found at address 1, status 0x786d. MII PHY #1 transceiver registers: 1100 786d 2000 5c10 01e1 41e1 0007 2801 0000 0000 0000 0000 0000 0000 0000 0000 0a25 0000 0000 0000 0000 0000 0020 0000 0080 0001 00a3 0100 0006 0f00 0000 0000. Basic mode control register 0x1100: Auto-negotiation enabled. Basic mode status register 0x786d ... 786d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 08:00:17:--:--:--, model 1 rev. 0. 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 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. Internal autonegotiation state is 'Autonegotiation disabled'. # tulip-diag -ee tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4D. EEPROM transceiver/media description table. 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 (64 words): 0x00: 1186 1112 0000 0000 0000 0000 0000 0000 0x08: 0067 0103 8000 b9c8 4d98 1e00 0000 0800 0x10: 8d01 0003 0000 7800 01e0 5000 1800 0000 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 19ed ID block CRC 0x67 (vs. 0x67). Full contents CRC 0x19ed (read as 0x19ed). MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. 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 256. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4E. EEPROM transceiver/media description table. 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 (64 words): 0x00: 1186 1112 0000 0000 0000 0000 0000 0000 0x08: 0067 0103 8000 b9c8 4e98 1e00 0000 0800 0x10: 8d01 0003 0000 7800 01e0 5000 1800 0000 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 8fed ID block CRC 0x67 (vs. 0x67). Full contents CRC 0x8fed (read as 0x8fed). MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. # tulip-diag -e tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4D. EEPROM transceiver/media description table. 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. MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. 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 256. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4E. EEPROM transceiver/media description table. 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. MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. From linuxkernel@amazing.ch Mon Jan 14 20:02:00 2002 From: linuxkernel@amazing.ch (Christoph Dworzak) Date: Mon Jan 14 20:02:00 2002 Subject: [tulip] 2.4.17 tulip multiport-patch Message-ID: <20020115020413.B11753@amazing.ch> Hi After lots of Headscratching, I found this little bug: replace line 1642 of tulip_core.c: irq = last_irq; with dev->irq = irq = last_irq; It's a hack for Multiport-NICs where only the first one contains an EEPROM (I have a Adaptec ANA-6944A/TX). It puts other ports on the same irq as the first one, but it forgot to actually set it in the dev-structure... With this correction my Firewall works like a champ now (before it crashed immediately when activating the second port of the multiport-nic). While searching for this Bug, I also tried the de4x5-driver. It worked, but with troubles. It sets the MAC-Address of all the other ports to the MAC of the first port + 1. ALL of them to the same MAC! I tried to find out why, but I didn't find this in the code (I found where it adds this 1, but didn't see why it doesn't increase it further for further ports...) Don't know if this is related: While using the de4x5-driver, my system-load climbed steadily up. After 3 Days it was at 99.5%. Top didn't show any processes using this time, but the Computer was reaaaaaly slow (pressing a key took several seconds until it appeared on the console...) This was repeatable. -> Reboot every other day :( If this happens again, how do I find out what's using the CPU? (I tried top, vmstat, free, but nothing unusual showed up beside the system-% in top). bye dworz Config (two Computers A and B): A Amd-k6/300, 64MB B Dual PIII-600, 512MB both with ANA-6944A/TX + 2 other tulips both RH7.2 with all updates as of 1.1.02 kernel 2.4.9-13 (the tulip-bug is still in 2.4.18pre3) Computer B would not slow down with DE4x5, but maybe it wasn't running long enough yet... Both crashed with tulip. From becker@scyld.com Mon Jan 14 21:01:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jan 14 21:01:01 2002 Subject: [tulip] 2.4.17 tulip multiport-patch In-Reply-To: <20020115020413.B11753@amazing.ch> Message-ID: On Tue, 15 Jan 2002, Christoph Dworzak wrote: > After lots of Headscratching, I found this little bug: > > replace line 1642 of tulip_core.c: > > irq = last_irq; > > with > > dev->irq = irq = last_irq; Hmmm, a little bit of bad conversion here. The tulip.c code follows this section by dev->irq = irq; a few lines later. > While using the de4x5-driver, my system-load climbed steadily > up. After 3 Days it was at 99.5%. Check the interrupt count in /dev/interrupts. > This was repeatable. -> Reboot every other day :( Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From motih@cisco.com Wed Jan 16 06:00:03 2002 From: motih@cisco.com (Moti Haimovsky) Date: Wed Jan 16 06:00:03 2002 Subject: [tulip] RE: problem with tulip card ceasing to function - requires ifdown/ifup to fix (Dani Roisman) In-Reply-To: <200201151704.g0FH4uR02422@blueraja.scyld.com> Message-ID: My name is Moti Haimovsky and I've worked as a software engineer in the group that developed the 2114x family of chips in Digital Semiconductor. My experience with the 2114x family started from the early days of the 21040 device and ending with the 21143. As such I'm willing to take the heat (and hit) from users of those products answering device related questions and more ... :) Thanks motih@cisco.com regarding Dani Roisman problem with tulip card ceasing to function - requires ifdown/ifup to fix : The registers dump of the tulip device at 0xc800: CSR5 val is: f0680000 CSR7 val is: fbfffbff The Rx process state is 'Suspended -- no Rx buffers'. Although the RX state reports it found no free rx buffer the RU (receive buffer unavailable) interrupt is not set in CSR5 which suggests that this interrupt had been acknowledged by the driver but still the receive process did not see a free descriptor to work with. in such situation (where RU interrupt was set by tulip) no further RI nor RU interrupts will be initiated by the chip until a chip-owned RX descriptor is recognized by the chip. The philosophy behind this strange behavior (if I remember correctly) is that RU situation indicates a busy system, and if the chip will keep interrupting the system it will only make things worse. This may very well happen in the following code located in tulip driver ISR when rx > maxrx: 1. In a heavily loaded system it may happen that the following code will be activated: if (tx > maxtx || rx > maxrx || oi > maxoi) { if (tulip_debug > 1) printk(KERN_WARNING "%s: Too much work during an interrupt, " "csr5=0x%8.8x. (%lu) (%d,%d,%d)\n", dev->name, csr5, tp->nir, tx, rx, oi); /* Acknowledge all interrupt sources. */ outl(0x8001ffff, ioaddr + CSR5); if (tp->flags & HAS_INTR_MITIGATION) { /* Josip Loncaric at ICASE did extensive experimentation to develop a good interrupt mitigation setting.*/ outl(0x8b240000, ioaddr + CSR11); } else { /* Mask all interrupting sources, set timer to re-enable. */ outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt, ioaddr + CSR7); outl(0x0012, ioaddr + CSR11); } break; } Suppose that RU interrupt is set by the tulip device just prior to performing the above section then the command outl(0x8001ffff, ioaddr + CSR5) will clear RU silencing our receive path for good. 2. When no skbufs are available for refilling the RX ring. Chip sets CSR5 RU, driver acknowledges it /* Let's see whether the interrupt really is for us */ csr5 = inl(ioaddr + CSR5); if ((csr5 & (NormalIntr|AbnormalIntr)) == 0) return; tp->nir++; do { /* Acknowledge all of the current interrupt sources ASAP. */ outl(csr5 & 0x0001ffff, ioaddr + CSR5); if (csr5 & (RxIntr | RxNoBuf)) { rx += tulip_rx(dev); tulip_refill_rx(dev); } tulip_refill_rx(dev) - failed getting SKBs and the rest is history. Why ifdown eth0 ; ifup eth0 help? The RX ring is reinitialized again making the tulip a happy chip. This may suggest that the no-skbuf scenario is the less probable one. Hope I didn't mess thigs up Moti. -----Original Message----- From: tulip-admin@scyld.com [mailto:tulip-admin@scyld.com]On Behalf Of tulip-request@scyld.com Sent: Tuesday, January 15, 2002 9:05 AM To: tulip@scyld.com Subject: tulip digest, Vol 1 #455 - 3 msgs Send tulip mailing list submissions to tulip@scyld.com To subscribe or unsubscribe via the World Wide Web, visit http://www.scyld.com/mailman/listinfo/tulip or, via email, send a message with subject or body 'help' to tulip-request@scyld.com You can reach the person managing the list at tulip-admin@scyld.com When replying, please edit your Subject line so it is more specific than "Re: Contents of tulip digest..." Today's Topics: 1. Re: problem with tulip card ceasing to function - requires ifdown/ifup to fix (Dani Roisman) 2. 2.4.17 tulip multiport-patch (Christoph Dworzak) 3. Re: 2.4.17 tulip multiport-patch (Donald Becker) --__--__-- Message: 1 Date: Mon, 14 Jan 2002 11:52:47 -0800 From: Dani Roisman To: tulip@scyld.com Subject: [tulip] Re: problem with tulip card ceasing to function - requires ifdown/ifup to fix ... following up my problems from 11/2001 .... We had a couple recurrances of the problem - where one interface on a DLINK DFE-570TX hangs, and requires an ifdown eth0 ; ifup eth0 to get going again. This time, I was able to get on and run some tulip-diag's before bringing up the interface. I know that Donlad B. wanted to see these. First the detection messages (FYI, since I'm only using eth0 and eth1, I've cut out messages for the other 2 interfaces to keep this email a bit shorter). I'll take suggestions, including what I should run next time to offer better troubleshooting information. Thank you! from dmesg: eth0: Digital DS21143-xD Tulip rev 65 at 0xc800, 00:80:C8:B9:98:4D, IRQ 12. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: MII transceiver #1 config 3100 status 7869 advertising 01e1. eth1: Digital DS21143-xD Tulip rev 65 at 0xc400, 00:80:C8:B9:98:4E, IRQ 5. 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 3100 status 7869 advertising 01e1. tulip.c:v0.92t 1/15/2001 Written by Donald Becker http://www.scyld.com/network/tulip.html # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:80:C8:B9:98:4D inet addr:WW.XX.YY.11 Bcast:WW.XX.YY.15 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2147483647 errors:0 dropped:94727 overruns:0 frame:0 TX packets:2147483647 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:12 Base address:0xc800 # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:80:C8:B9:98:4E inet addr:WW.XX.YY.1 Bcast:WW.XX.YY.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2147483647 errors:0 dropped:3 overruns:0 frame:0 TX packets:2147483647 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 Base address:0xc400 # tulip-diag -aa tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21143 Tulip chip registers at 0xc800: 0x00: f8a08000 ffffffff ffffffff 07fee800 07feea00 f0680000 b20e2202 fbfffbff Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21143 Tulip chip registers at 0xc400: 0x00: f8a08000 ffffffff ffffffff 07fee000 07fee200 f0660000 b20e6202 fbfffbff 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 256. The NWay status register is 000000c6. # tulip-diag -mm tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. MII PHY found at address 1, status 0x786d. MII PHY #1 transceiver registers: 1100 786d 2000 5c10 01e1 41e1 0007 2801 0000 0000 0000 0000 0000 0000 0000 0000 0a25 0000 0000 0000 0000 0000 0020 0000 0080 0001 00a3 0100 0006 0f00 0000 0000. Basic mode control register 0x1100: Auto-negotiation enabled. Basic mode status register 0x786d ... 786d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 08:00:17:--:--:--, model 1 rev. 0. 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 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. 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 256. The NWay status register is 000000c6. MII PHY found at address 1, status 0x786d. MII PHY #1 transceiver registers: 1100 786d 2000 5c10 01e1 41e1 0007 2801 0000 0000 0000 0000 0000 0000 0000 0000 0a25 0000 0000 0000 0000 0000 0020 0000 0080 0001 00a3 0100 0006 0f00 0000 0000. Basic mode control register 0x1100: Auto-negotiation enabled. Basic mode status register 0x786d ... 786d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 08:00:17:--:--:--, model 1 rev. 0. 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 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. Internal autonegotiation state is 'Autonegotiation disabled'. # tulip-diag -ee tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4D. EEPROM transceiver/media description table. 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 (64 words): 0x00: 1186 1112 0000 0000 0000 0000 0000 0000 0x08: 0067 0103 8000 b9c8 4d98 1e00 0000 0800 0x10: 8d01 0003 0000 7800 01e0 5000 1800 0000 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 19ed ID block CRC 0x67 (vs. 0x67). Full contents CRC 0x19ed (read as 0x19ed). MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. 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 256. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4E. EEPROM transceiver/media description table. 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 (64 words): 0x00: 1186 1112 0000 0000 0000 0000 0000 0000 0x08: 0067 0103 8000 b9c8 4e98 1e00 0000 0800 0x10: 8d01 0003 0000 7800 01e0 5000 1800 0000 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 8fed ID block CRC 0x67 (vs. 0x67). Full contents CRC 0x8fed (read as 0x8fed). MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. # tulip-diag -e tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4D. EEPROM transceiver/media description table. 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. MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. 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 256. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:B9:98:4E. EEPROM transceiver/media description table. 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. MII PHY found at address 1, status 0x786d. Internal autonegotiation state is 'Autonegotiation disabled'. --__--__-- Message: 2 Date: Tue, 15 Jan 2002 02:04:13 +0100 From: Christoph Dworzak To: linux-kernel@vger.kernel.org Cc: tulip@scyld.com Subject: [tulip] 2.4.17 tulip multiport-patch Hi After lots of Headscratching, I found this little bug: replace line 1642 of tulip_core.c: irq = last_irq; with dev->irq = irq = last_irq; It's a hack for Multiport-NICs where only the first one contains an EEPROM (I have a Adaptec ANA-6944A/TX). It puts other ports on the same irq as the first one, but it forgot to actually set it in the dev-structure... With this correction my Firewall works like a champ now (before it crashed immediately when activating the second port of the multiport-nic). While searching for this Bug, I also tried the de4x5-driver. It worked, but with troubles. It sets the MAC-Address of all the other ports to the MAC of the first port + 1. ALL of them to the same MAC! I tried to find out why, but I didn't find this in the code (I found where it adds this 1, but didn't see why it doesn't increase it further for further ports...) Don't know if this is related: While using the de4x5-driver, my system-load climbed steadily up. After 3 Days it was at 99.5%. Top didn't show any processes using this time, but the Computer was reaaaaaly slow (pressing a key took several seconds until it appeared on the console...) This was repeatable. -> Reboot every other day :( If this happens again, how do I find out what's using the CPU? (I tried top, vmstat, free, but nothing unusual showed up beside the system-% in top). bye dworz Config (two Computers A and B): A Amd-k6/300, 64MB B Dual PIII-600, 512MB both with ANA-6944A/TX + 2 other tulips both RH7.2 with all updates as of 1.1.02 kernel 2.4.9-13 (the tulip-bug is still in 2.4.18pre3) Computer B would not slow down with DE4x5, but maybe it wasn't running long enough yet... Both crashed with tulip. --__--__-- Message: 3 Date: Mon, 14 Jan 2002 21:03:00 -0500 (EST) From: Donald Becker To: Christoph Dworzak cc: linux-kernel@vger.kernel.org, tulip@scyld.com Subject: Re: [tulip] 2.4.17 tulip multiport-patch On Tue, 15 Jan 2002, Christoph Dworzak wrote: > After lots of Headscratching, I found this little bug: > > replace line 1642 of tulip_core.c: > > irq = last_irq; > > with > > dev->irq = irq = last_irq; Hmmm, a little bit of bad conversion here. The tulip.c code follows this section by dev->irq = irq; a few lines later. > While using the de4x5-driver, my system-load climbed steadily > up. After 3 Days it was at 99.5%. Check the interrupt count in /dev/interrupts. > This was repeatable. -> Reboot every other day :( Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 --__--__-- _______________________________________________ tulip mailing list tulip@scyld.com http://www.scyld.com/mailman/listinfo/tulip End of tulip Digest From bsr@mercury.co.il Wed Jan 16 07:01:01 2002 From: bsr@mercury.co.il (Baruch Shpirer) Date: Wed Jan 16 07:01:01 2002 Subject: [tulip] tulip driver for CONEXANT NIC for kernel 2.4.9-12 Message-ID: Hi, Did anyone manage to compile tulip module to this kernel ? I get unresolved symbols and nothing works , errr... From Narayanan Vydianathan Wed Jan 16 15:53:01 2002 From: Narayanan Vydianathan (Narayanan Vydianathan) Date: Wed Jan 16 15:53:01 2002 Subject: [tulip] Removing the tulip driver Message-ID: <200201162052.MAA15010@phys-ha10nwka.ebay.sun.com> Hi, I had tulip driver installed in my pentium system with Red Hat Linux 7.2 Everything was working fine, yesterday while booting the system hung while bringing up eth0. After I rebooted the system it is not recognizing the NIC card. ifconfig displays only local loop back. I use DHCP to through a cable modem to connect to internet. Also I tried to check the card therogh "gnome" hardware check. It says the card is not initilaized . I would like to completely remove the driver and reinstall it. Could someone tell me the procedure? The NIC card is completely functional as I am able to use it from "Windows XP" in the same system. I have a dual boot system. Thanks --Narayanan --------------------------------------------------------------------- Narayanan Vydianathan (W) (510)-574-9189 From mistral@stev.org Wed Jan 16 17:55:01 2002 From: mistral@stev.org (James Stevenson) Date: Wed Jan 16 17:55:01 2002 Subject: [tulip] overruns ? Message-ID: <03ed01c19ec7$2d030e20$0801a8c0@Stev.org> Hi i have 2 cards from SMC each in 2 different computers and a 100mbps switch both work fine well almost in Full Duplex 100mbps. though there are 2 things. they show up in /proc/pci as Ethernet controller: Accton Technology Corporation EN-1216 Ethernet Adapter (rev 17). IRQ 10. Master Capable. Latency=64. Min Gnt=255.Max Lat=255. I/O at 0xe400 [0xe4ff]. Non-prefetchable 32 bit memory at 0xea400000 [0xea4003ff]. but thats not causing any problems i am aware of. The big problem i am having is the number of overruns currently it looks a bit like this eth0 Link encap:Ethernet HWaddr 00:04:E2:1E:FE:B3 inet addr:192.168.1.1 Bcast:255.255.255.0 Mask:255.255.255.0 inet6 addr: fe80::204:e2ff:fe1e:feb3/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1339805 errors:356 dropped:0 overruns:356 frame:356 TX packets:1403114 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:485550324 (463.0 Mb) TX bytes:767819780 (732.2 Mb) Interrupt:10 Base address:0xe400 i have not been stressing the connection much because i have not been home but i can generate up to 20-25% of the packets being counted in overruns. this happens on both machine when they are idle (eg 90%) a P233 with 192MB ram and a cyrix P200 with 128MB of ram. is there anything i can do to prevent these its a bit of a performance loss. The dmesg shows its an ADMtek COMET if this is any help apart from that they seem to work fine. Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) PCI: Found IRQ 10 for device 00:09.0 eth0: ADMtek Comet rev 17 at 0xe400, 00:04:E2:1E:FE:B3, IRQ 10. thanks James -------------------------- Mobile: +44 07779080838 http://www.stev.org 7:40pm up 2 days, 19:09, 2 users, load average: 0.00, 0.04, 0.12 From becker@scyld.com Wed Jan 16 19:23:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jan 16 19:23:00 2002 Subject: [tulip] overruns ? In-Reply-To: <03ed01c19ec7$2d030e20$0801a8c0@Stev.org> Message-ID: On Wed, 16 Jan 2002, James Stevenson wrote: > i have 2 cards from SMC each in 2 different computers and a 100mbps switch > both work fine well almost in Full Duplex 100mbps. What is the detection message? What does 'mii-diag' or 'tulip-diag -m' report? > eth0 Link encap:Ethernet HWaddr 00:04:E2:1E:FE:B3 > RX packets:1339805 errors:356 dropped:0 overruns:356 frame:356 > TX packets:1403114 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 This could be a duplex mismatch. If the link partner is not in full duplex mode, it will abort transmit on out-of-window collisions. You will interpret that as receiving packets with CRC errors. There are other possibilities. What does /proc/net/dev report? Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From mistral@stev.org Thu Jan 17 15:05:01 2002 From: mistral@stev.org (James Stevenson) Date: Thu Jan 17 15:05:01 2002 Subject: [tulip] overruns ? References: Message-ID: <003701c19f8b$f3a2fc60$0801a8c0@Stev.org> > On Wed, 16 Jan 2002, James Stevenson wrote: > > i have 2 cards from SMC each in 2 different computers and a 100mbps switch > > both work fine well almost in Full Duplex 100mbps. > > What is the detection message? > > What does 'mii-diag' or 'tulip-diag -m' report? not sure where can i get the utility ? http://www.scyld.com ? > > eth0 Link encap:Ethernet HWaddr 00:04:E2:1E:FE:B3 > > RX packets:1339805 errors:356 dropped:0 overruns:356 frame:356 > > TX packets:1403114 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:100 > > This could be a duplex mismatch. If the link partner is not in full > duplex mode, it will abort transmit on out-of-window collisions. You > will interpret that as receiving packets with CRC errors. > > There are other possibilities. What does /proc/net/dev report? face bytes packets errs drop fifo frame compressed multicast eth0 531841837 1702596 356 0 356 356 0 0 bytes packets errs drop fifo colls carrier compressed 1065809667 1866746 0 0 0 0 0 0 any ideas what would cause it ? thanks James From becker@scyld.com Thu Jan 17 15:17:00 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jan 17 15:17:00 2002 Subject: [tulip] overruns ? In-Reply-To: <003701c19f8b$f3a2fc60$0801a8c0@Stev.org> Message-ID: On Thu, 17 Jan 2002, James Stevenson wrote: > > On Wed, 16 Jan 2002, James Stevenson wrote: > > > i have 2 cards from SMC each in 2 different computers and a 100mbps > switch > > > both work fine well almost in Full Duplex 100mbps. > > > > What is the detection message? What is the detection message? > > What does 'mii-diag' or 'tulip-diag -m' report? > not sure where can i get the utility ? > http://www.scyld.com ? http://www.scyld.com/diag/index.html > > > eth0 Link encap:Ethernet HWaddr 00:04:E2:1E:FE:B3 > > > RX packets:1339805 errors:356 dropped:0 overruns:356 frame:356 > > > TX packets:1403114 errors:0 dropped:0 overruns:0 carrier:0 > > > collisions:0 txqueuelen:100 > > > > This could be a duplex mismatch. If the link partner is not in full > > duplex mode, it will abort transmit on out-of-window collisions. You > > will interpret that as receiving packets with CRC errors. > > > > There are other possibilities. What does /proc/net/dev report? > > face bytes packets errs drop fifo frame compressed multicast > eth0 531841837 1702596 356 0 356 356 0 0 This still looks pretty much like a duplex mismatch. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From mistral@stev.org Thu Jan 17 17:03:01 2002 From: mistral@stev.org (James Stevenson) Date: Thu Jan 17 17:03:01 2002 Subject: [tulip] overruns ? References: Message-ID: <04ad01c19fa2$74850ec0$0801a8c0@Stev.org> Hi > On Thu, 17 Jan 2002, James Stevenson wrote: > > > > On Wed, 16 Jan 2002, James Stevenson wrote: > > > > i have 2 cards from SMC each in 2 different computers and a 100mbps > > switch > > > > both work fine well almost in Full Duplex 100mbps. > > > > > > What is the detection message? > > What is the detection message? Using the default interface 'eth0'. Basic registers of MII PHY #1: 3000 786d 0022 5410 01e1 45e1 0005 2801. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3000: 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. End of basic transceiver information. > > > What does 'mii-diag' or 'tulip-diag -m' report? > > not sure where can i get the utility ? > > http://www.scyld.com ? > > http://www.scyld.com/diag/index.html > > > > > eth0 Link encap:Ethernet HWaddr 00:04:E2:1E:FE:B3 > > > > RX packets:1339805 errors:356 dropped:0 overruns:356 frame:356 > > > > TX packets:1403114 errors:0 dropped:0 overruns:0 carrier:0 > > > > collisions:0 txqueuelen:100 > > > > > > This could be a duplex mismatch. If the link partner is not in full > > > duplex mode, it will abort transmit on out-of-window collisions. You > > > will interpret that as receiving packets with CRC errors. > > > > > > There are other possibilities. What does /proc/net/dev report? > > > > face bytes packets errs drop fifo frame compressed multicast > > eth0 531841837 1702596 356 0 356 356 0 0 > > This still looks pretty much like a duplex mismatch. From becker@scyld.com Thu Jan 17 17:19:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jan 17 17:19:01 2002 Subject: [tulip] overruns ? In-Reply-To: <04ad01c19fa2$74850ec0$0801a8c0@Stev.org> Message-ID: On Thu, 17 Jan 2002, James Stevenson wrote: > > On Thu, 17 Jan 2002, James Stevenson wrote: > > > > > > On Wed, 16 Jan 2002, James Stevenson wrote: > > > > > i have 2 cards from SMC each in 2 different computers and a 100mbps > > > switch > > > > > both work fine well almost in Full Duplex 100mbps. > > > > > > > > What is the detection message? > > > > What is the detection message? > Using the default interface 'eth0'. > Basic registers of MII PHY #1: 3000 786d 0022 5410 01e1 45e1 0005 2801. What is the detection message? The driver detection message, including the version number and information about the chip and supported media types. In this case the driver version and specific chip in use is important. > The autonegotiated capability is 01e0. > The autonegotiated media type is 100baseTx-FD. > Basic mode control register 0x3000: 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. > End of basic transceiver information. > > Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From mistral@stev.org Thu Jan 17 17:59:01 2002 From: mistral@stev.org (James Stevenson) Date: Thu Jan 17 17:59:01 2002 Subject: [tulip] overruns ? References: Message-ID: <04bd01c19fa8$63c91850$0801a8c0@Stev.org> > On Thu, 17 Jan 2002, James Stevenson wrote: > > > > On Thu, 17 Jan 2002, James Stevenson wrote: > > > > > > > > On Wed, 16 Jan 2002, James Stevenson wrote: > > > > > > i have 2 cards from SMC each in 2 different computers and a 100mbps > > > > switch > > > > > > both work fine well almost in Full Duplex 100mbps. > > > > > > > > > > What is the detection message? > > > > > > What is the detection message? > > > Using the default interface 'eth0'. > > Basic registers of MII PHY #1: 3000 786d 0022 5410 01e1 45e1 0005 2801. > > What is the detection message? > The driver detection message, including the version number and > information about the chip and supported media types. >From /proc/pci under 2.4.17 Ethernet controller: Accton Technology Corporation EN-1216 Ethernet Adapter (rev 17). IRQ 10. Master Capable. Latency=64. Min Gnt=255.Max Lat=255. I/O at 0xe400 [0xe4ff]. >From ls pci 00:09.0 Ethernet controller: Accton Technology Corporation: Unknown device 1216 (rev 11) 00:09.0 Class 0200: 1113:1216 (rev 11) >From dmesg Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) PCI: Found IRQ 10 for device 00:09.0 eth0: ADMtek Comet rev 17 at 0xe400, 00:04:E2:1E:FE:B3, IRQ 10. >From the box :) SMC 1255TX if i new where tio get the doc's for the card i would have a go and debugging it myself. > In this case the driver version and specific chip in use is important. > > > The autonegotiated capability is 01e0. > > The autonegotiated media type is 100baseTx-FD. > > Basic mode control register 0x3000: 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. > > End of basic transceiver information. From manish.kurup2@verizon.net Thu Jan 17 18:41:01 2002 From: manish.kurup2@verizon.net (Manish Kurup) Date: Thu Jan 17 18:41:01 2002 Subject: [tulip] Problems with Redhat 7.2 networking ... Message-ID: <3C4760D3.6560F8E5@verizon.net> Hi, I have a Compaq Presario 5690 with a DEC 21143 (tulip chip) on the network card. I was using RedHat 6.1 successfully with my DSL connection, going directly into the DSL modem and PPoE (Roaring Penguin stack). All was well until I bought a Linksys 4 port Cable/DSL router (BEFSR41 V.2). Now my configured eth0 interface refuses to boot up, The Linksys router refuses to recognize my ethernet card. I think the card tries to configure itself as a 100Mbps interface and that really screws things up. I know this because the 100 Mbps light on my router keeps blinking as well as the collisions light, and I do see carrier errors and Tx errors when I do an ifconfig. Upgrading to Redhat 7.2 doesnt seem to solve this problem as well Can someone tell me how I can set up my network card to work in this configuration. OH, the tulip-diags program says that the card is being setup in 100Mbps full duplex and no MII transceivers found. I have tried insmod'ing the tulip driver with different options like 0=auto, 1, 2, 3, 4 ... nothing seems to work would greatly appreciate any help on this matter .... Thanks in advance. .. Manish. From becker@scyld.com Fri Jan 18 14:36:03 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jan 18 14:36:03 2002 Subject: [tulip] Problems with Redhat 7.2 networking ... In-Reply-To: <3C4760D3.6560F8E5@verizon.net> Message-ID: On Thu, 17 Jan 2002, Manish Kurup wrote: > I have a Compaq Presario 5690 with a DEC 21143 (tulip chip) on the > network card. I was using RedHat 6.1 successfully with my DSL > connection, going directly into the DSL modem and PPoE (Roaring Penguin > stack). All was well until I bought a Linksys 4 port Cable/DSL router > (BEFSR41 V.2). My guess: you have a 21143 with a SYM transceiver. > Upgrading to Redhat 7.2 doesnt seem to solve this problem as well. It won't -- with a SYM transceiver, the RH7.2 behavior is worse. You need an updated driver. Use http://www.scyld.com/network/tulip.html ftp://www.scyld.com/pub/network/tulip.c Info update: With RH7.2 be certain that you have the full and proper kernel sources installed. The "kernel-headers" package no longer contains kernel headers! This has been the cause of many symbol-mismatch reports on the list. > Can someone tell me how I can set up my network card to work in this > configuration. OH, the tulip-diags program says that the card is being > setup in 100Mbps full duplex and no MII transceivers found. I have tried > insmod'ing the tulip driver with different options like 0=auto, 1, 2, 3, > 4 ... nothing seems to work would greatly appreciate any help on this > matter .... Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri Jan 18 16:45:02 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jan 18 16:45:02 2002 Subject: [tulip] overruns ? In-Reply-To: <04bd01c19fa8$63c91850$0801a8c0@Stev.org> Message-ID: On Thu, 17 Jan 2002, James Stevenson wrote: > >From /proc/pci under 2.4.17 > > Ethernet controller: Accton Technology Corporation EN-1216 Ethernet Adapter > (rev 17). ... > 00:09.0 Ethernet controller: Accton Technology Corporation: Unknown device > 1216 (rev 11) > 00:09.0 Class 0200: 1113:1216 (rev 11) That's an ADMtek Comet chip. > >From dmesg > Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) Try http://www.scyld.com/network/tulip.html ftp://www.scyld.com/pub/network/tulip.c Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jdparker.antispam@home.com Fri Jan 18 23:02:00 2002 From: jdparker.antispam@home.com (James D Parker Jr) Date: Fri Jan 18 23:02:00 2002 Subject: [tulip] Issues getting driver to work in Red Hat References: Message-ID: <3C48EFED.A58A7CDD@home.com> I found a web page that descibes how to get a Linksys network card to work in Red Hat. This was for an older version of the card/driver that did not require pci-scan. The instructions were something like: 1. compile tulip 2. put tulip.o in the proper modules directory 3. run "modprobe tulip" and "depmond -a" in some order ( I foget which) 4. add "alias eth0 tulip" to /etc/modules.conf 5. run netcfg to configure This did work even for a Linksys card that is supposed to require the latest drivers. That is the way my system is currently set up. The instructions on the scyld web page for installing the newer drivers individually go something like this: 1. compile tulip.c and pci-scan.c 2. run insmod for the the two modules 3. run install for the two modules There is no mention of adding anything to /etc/modules.conf or running netcfg. Does this mean that these are not necessay? What is the difference between modprobe/depmod and insmod/install? (I have done man on each but unfortunately I only have a masters degree in computer science so I can't understand them.) BTW: the warning about not being able to compile the drivers with gcc under Red Hat 7.0 may not apply if you have applied the correct Red Hat supplied fixes. I have downloaded tulip.c, pci-scan.c/h and kern_compat.h and got only the following warning messages compiling tulip.c and pci-scan.c. tulip: /tmp/ccYHGnea.s: Assembler messages: /tmp/ccYHGnea.s:145: Warning: Ignoring changed section attributes for .modinfo pci-scan: /tmp/cc9gkOLV.s: Assembler messages: /tmp/cc9gkOLV.s:25: Warning: Ignoring changed section attributes for .modinfo What is the significance of these warnings? Thanks Jim From prc@theriver.com Sat Jan 19 09:49:01 2002 From: prc@theriver.com (prc@theriver.com) Date: Sat Jan 19 09:49:01 2002 Subject: [tulip] Issues getting driver to work in Red Hat Message-ID: <20020119144803.486FF1A937E@pantano.theriver.com> unsubscribe >I found a web page that descibes how to get a Linksys network card to work in >Red Hat. This was for an older version of the card/driver that did not require >pci-scan. The instructions were something like: >1. compile tulip >2. put tulip.o in the proper modules directory >3. run "modprobe tulip" and "depmond -a" in some order ( I foget which) >4. add "alias eth0 tulip" to /etc/modules.conf >5. run netcfg to configure > >This did work even for a Linksys card that is supposed to require the latest >drivers. That is the way my system is currently set up. > >The instructions on the scyld web page for installing the newer drivers >individually go something like this: >1. compile tulip.c and pci-scan.c >2. run insmod for the the two modules >3. run install for the two modules > >There is no mention of adding anything to /etc/modules.conf or running netcfg. >Does this mean that these are not necessay? > >What is the difference between modprobe/depmod and insmod/install? (I have done >man on each but unfortunately I only have a masters degree in computer science >so I can't understand them.) > >BTW: the warning about not being able to compile the drivers with gcc under Red >Hat 7.0 may not apply if you have applied the correct Red Hat supplied fixes. >I have downloaded tulip.c, pci-scan.c/h and kern_compat.h and got only the >following warning messages compiling tulip.c and pci-scan.c. > >tulip: >/tmp/ccYHGnea.s: Assembler messages: >/tmp/ccYHGnea.s:145: Warning: Ignoring changed section attributes for .modinfo > >pci-scan: >/tmp/cc9gkOLV.s: Assembler messages: >/tmp/cc9gkOLV.s:25: Warning: Ignoring changed section attributes for .modinfo > >What is the significance of these warnings? > >Thanks >Jim > >_______________________________________________ >tulip mailing list, tulip@scyld.com >To change to digest mode or unsubscribe visit >http://www.scyld.com/mailman/listinfo/tulip > > From mistral@stev.org Sat Jan 19 09:58:01 2002 From: mistral@stev.org (James Stevenson) Date: Sat Jan 19 09:58:01 2002 Subject: [tulip] overruns ? References: Message-ID: <00d501c1a0ee$b69c9420$0801a8c0@Stev.org> > On Thu, 17 Jan 2002, James Stevenson wrote: > > >From /proc/pci under 2.4.17 > > > > Ethernet controller: Accton Technology Corporation EN-1216 Ethernet Adapter > > (rev 17). > .. > > >From dmesg > > Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) > > Try > http://www.scyld.com/network/tulip.html > ftp://www.scyld.com/pub/network/tulip.c The page does not really tell me anything i dont alreay know unless i am missing something ? if the driver there the same as the version in 2.4.17 ? James From jmichael@msn.fullfeed.com Sat Jan 19 11:29:01 2002 From: jmichael@msn.fullfeed.com (Justin C . Michael) Date: Sat Jan 19 11:29:01 2002 Subject: [tulip] overruns ? In-Reply-To: <00d501c1a0ee$b69c9420$0801a8c0@Stev.org>; from mistral@stev.org on Sat, Jan 19, 2002 at 01:39:26PM -0000 References: <00d501c1a0ee$b69c9420$0801a8c0@Stev.org> Message-ID: <20020119102850.A15632@condor.msn.fullfeed.com> On Sat, Jan 19, 2002 at 01:39:26PM -0000, James Stevenson wrote: > The page does not really tell me anything i dont > alreay know unless i am missing something ? > > if the driver there the same as the version in > 2.4.17 ? > no, 2.4.17 has 0.9.15-pre9 and the page has 0.9.3 the web page tells you about the driver, the ftp is the 0.9.3 version of the driver itself. --j From becker@scyld.com Sat Jan 19 12:57:01 2002 From: becker@scyld.com (Donald Becker) Date: Sat Jan 19 12:57:01 2002 Subject: [tulip] overruns ? In-Reply-To: <00d501c1a0ee$b69c9420$0801a8c0@Stev.org> Message-ID: On Sat, 19 Jan 2002, James Stevenson wrote: > > On Thu, 17 Jan 2002, James Stevenson wrote: > > > >From /proc/pci under 2.4.17 > > > > > > Ethernet controller: Accton Technology Corporation EN-1216 Ethernet > Adapter > > > (rev 17). > > .. > > > >From dmesg > > > Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) This is a modified driver -- this version number format does not match my release. > The page does not really tell me anything i dont > alreay know unless i am missing something ? > > if the driver there the same as the version in > 2.4.17 ? It is not. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From gregg@wwti.com Sun Jan 20 04:14:01 2002 From: gregg@wwti.com (Gregg Graubins) Date: Sun Jan 20 04:14:01 2002 Subject: [tulip] tulip v0.93 (11/7/01) problems for DS21140 quad card under RH 2.2.19 In-Reply-To: Message-ID: <000301c1a192$dba279c0$0a01a8c0@uranus> > On Wed, 9 Jan 2002, Gregg Graubins wrote: > > > [root@freedom net]# insmod -v pci-scan.o > > Using pci-scan.o > > Symbol version prefix 'smp_' > > pci-scan.o: kernel-module version mismatch > > pci-scan.o was compiled for kernel version 2.2.16-22 > > while this kernel is version 2.2.19. > .. > > I did notice the report about the kernel version above, but that > > shouldn't have any affect on trying to load the module, right? > > That's the problem -- symbol mismatches are caused by > compiling with the wrong kernel header files. If you have > modversions enabled, you must use exactly the header files > for your specific kernel. The version I tried with my 2.2.19 kernel was the one currently found at ftp://ftp.scyld.com/pub/network/tulip.c (v0.93 11/7/2001) that says it should work with all kernels from before 1.2.0 through the current 2.2 version. Orlando Rocha (Thanks Orlando!) sent me a tulip.tar that has v0.92wa 7/11/2001 in it. I compiled that one separately, tried loading it as a module (insmod), and it worked just fine (Of course installing pci-scan.o first). Maybe it's just the version I originally downloaded (v0.93 11/7/2001) being a little incompatible with 2.2.19? Or maybe it was just me. But in any case, it's working now. Thanks for your help (Both Donald and Orlando)! === Gregg Graubins (PGP key available) From gregg@wwti.com Sun Jan 20 15:21:01 2002 From: gregg@wwti.com (Gregg Graubins) Date: Sun Jan 20 15:21:01 2002 Subject: [tulip] tulip v0.93 (11/7/01) problems for DS21140 quad card under RH 2.2.19 (problem solved) In-Reply-To: Message-ID: <000001c1a1f0$2261eaf0$0a01a8c0@uranus> This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1A1BD.D7C77AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (This just an email to the mailing list for those who may have a similar problem in the future - Give this a shot [archival purposes]) > Greetings, > > I'm having a problem compiling the tulip module drivers into my 2.2.19 > kernel. I have RedHat 7.1 installed and am downgrading the kernel to > 2.2.19. Per the instructions, I downloaded the individual driver file > (tulip.c), pci-scan.c, pci-scan.h, and kern_compat.h and placed them > in my kernel drivers/net directory and recompiled without any errors. > > BTW, I placed tulip.o and pci-scan.o in the modules directory > (/lib/modules/2.2.19/net). > > The problem I'm having is upon trying to load the module (insmod). > It's giving some unresolved symbol errors, as shown here: > > ======================================================================== === > [root@freedom net]# insmod -v tulip.o > Using tulip.o > Symbol version prefix 'smp_' > tulip.o: unresolved symbol pci_drv_unregister > tulip.o: unresolved symbol pci_drv_register > ======================================================================== === > > These are found in pci-scan.c... I don't have a whole lot of > experience with modules, but I also tried: > > ======================================================================== === > [root@freedom net]# insmod -v pci-scan.o > Using pci-scan.o > Symbol version prefix 'smp_' > pci-scan.o: kernel-module version mismatch > pci-scan.o was compiled for kernel version 2.2.16-22 > while this kernel is version 2.2.19. > > [root@freedom net]# insmod -f -v pci-scan.o > Using pci-scan.o > Symbol version prefix 'smp_' > Warning: kernel-module version mismatch > pci-scan.o was compiled for kernel version 2.2.16-22 > while this kernel is version 2.2.19 > pci-scan.o: unresolved symbol __ioremap_R9eac042a > pci-scan.o: unresolved symbol pci_find_class_R6c460806 > pci-scan.o: unresolved symbol pci_write_config_word_Rd9cc3b03 > pci-scan.o: unresolved symbol pci_write_config_dword_Rf0fbd200 > pci-scan.o: unresolved symbol pci_read_config_dword_R2ca7e89f > pci-scan.o: unresolved symbol pci_read_config_byte_Re5ceea13 > pci-scan.o: unresolved symbol pci_write_config_byte_Re84d5397 > pci-scan.o: unresolved symbol check_region_R522f4d72 > pci-scan.o: unresolved symbol pci_set_master_R040f6432 > pci-scan.o: unresolved symbol printk_R1b7d4074 > pci-scan.o: unresolved symbol pci_read_config_word_R8764d15f > ======================================================================== === > > I did notice the report about the kernel version above, but that > shouldn't have any affect on trying to load the module, right? > > I also tried compiling the tulip drivers without having it load as a > module (monolithically) and it still doesn't work. > > FYI - The tulip module drivers with the 2.4.2-2 kernel that comes with > RH 7.1 works just fine. I checked into this a little more and found out that there was a problem with my command line args while compiling the modules. I [originally] followed the procedure at http://www.scyld.com/network/updates.html (and failed): > Compile both the driver file and pci-scan.c using the compile-command at the bottom of the source files. If a compile-command is not there use the following compile command: > gcc -DMODULE -D__KERNEL__ -O6 -c driver.c > gcc -DMODULE -D__KERNEL__ -O6 -c pci-scan.c > With some distributions, especially those based on the 2.4 kernel, > you may need to add the following options to the compile command > -I/usr/src/linux/include -include /usr/src/linux/include/linux/modversions.h Of course this was while I was under RH 7.1 2.4.2 I believe. The problem _might_ have been the gcc version (2.96 20000731 (Red Hat Linux 7.1 2.96-85)) I was trying to compile with. It should have been kgcc (However, I think I remember trying kgcc and that was still stubborn). In any case, I compiled using gcc while under a 2.2.19 kernel with the attached Makefile and it worked just fine when compiling v0.93. === Gregg Graubins (PGP key available) ------=_NextPart_000_0001_01C1A1BD.D7C77AF0 Content-Type: application/octet-stream; name="Makefile" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Makefile" CC =3D gcc=0A= OPTIONSCOMMON =3D -D__KERNEL__ -DMODULE -Wall -Wstrict-prototypes -O2 = -I/usr/src/linux/include -fomit-frame-pointer -fno-strict-aliasing = -Wno-trigraphs -fno-common -pipe -mpreferred-stack-boundary=3D2 = -march=3Di686 -DMODVERSIONS -include = /usr/src/linux/include/linux/modversions.h=0A= OPTIONSTULIP =3D $(OPTIONSCOMMON)=0A= OPTIONSPCISN =3D $(OPTIONSCOMMON) -DEXPORT_SYMTAB=0A= =0A= all:=0A= $(CC) $(OPTIONSTULIP) -c tulip.c=0A= $(CC) $(OPTIONSPCISN) -c pci-scan.c=0A= =0A= clean:=0A= rm -f *~ pci-scan.o tulip.o=0A= ------=_NextPart_000_0001_01C1A1BD.D7C77AF0-- From rgreen@world.std.com Sun Jan 20 23:42:00 2002 From: rgreen@world.std.com (Bob Green) Date: Sun Jan 20 23:42:00 2002 Subject: [tulip] SMC EZ Card 10/100 Mbps PC Card - tulip supported? Message-ID: <200201210437.XAA01129@localhost.localdomain> I am trying to configure a new pcmcia ethernet card I bought for my laptop. The exact model (as written on the box) is SMC EZ Card 10/100 Mbps PC Card (SMC8041TX).  The reason I believe this card might be supported by tulip is that in the file SUPPORTED.CARDS that comes with the pcmcia-cs-3.1.31 tarball, it lists "SMC EZ CardBus 10/100 Ethernet" as a supported card for tulip_cb.  I'm running kernel 2.4.9-13, so my understanding is that the support provided by tulip_cb has been rolled into tulip using the new hotplug mechanism.  Am I on target so far? I did a "cardctl ident" and got: Socket 0:   no product info available Socket 1:   product info: "SMC", "8041TX-10/100-PC-Card", "", ""   manfid: 0x01bf, 0x8041   function: 6 (network) So, I added this manfid info to /etc/pcmcia/config with the following entry: card "SMC 8041TX-10/100-PC-Card"   manfid 0x01bf, 0x8041   bind "tulip" Once I did this, inserting the card yields one high and one low beep.   Looking at /var/log/messages, I see the following output corresponding to this event: ---8<--- Jan 19 09:56:04 localhost kernel: Linux Tulip driver version 1.1.8 (June 16, 2001) Jan 19 09:56:04 localhost cardmgr[2164]: + /lib/modules/2.4.9-13/kernel/drivers/net/tulip/tulip.o: init_module: No such device Jan 19 09:56:04 localhost cardmgr[2164]: + /lib/modules/2.4.9-13/kernel/drivers/net/tulip/tulip.o: insmod /lib/modules/2.4.9-13/kernel/drivers/net/tulip/tulip.o failed Jan 19 09:56:04 localhost cardmgr[2164]: + /lib/modules/2.4.9-13/kernel/drivers/net/tulip/tulip.o: insmod tulip failed Jan 19 09:56:04 localhost cardmgr[2164]: + Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters Jan 19 09:56:04 localhost cardmgr[2164]: modprobe exited with status 255 Jan 19 09:56:04 localhost cardmgr[2164]: module /lib/modules/2.4.9-13/pcmcia/tulip.o not available Jan 19 09:56:05 localhost cardmgr[2164]: get dev info on socket 1 failed: Resource temporarily unavailable ---8<--- I hand installed Tulip 1.1.8, after I first got the same or very similar results with 0.9.14pre, the version that came with my kernel.   My questions are: - Is the "init_module: No such device" error an indication that there is something wrong with my configuration, or does it indicate that tulip does not recognize the card? - Is there a parameter I can run tulip with to get more detailed error messages.  I tried "insmod tulip debug=3" without success. - Am I correct in believing I should be using the tulip driver and not driver to compile the tulip_cb driver for the 2.4 kernel? - If this card is not supported, can anyone recommend a well-supported (by tulip or otherwise) pcmcia 100 Mbps ethernet card? I'm thinking about a Linksys EtherFast 10/100 CardBus PC Card (PCMPC200) which appears to be supported by tulip, anyone know for sure if it works? Thanks, Bob From alvin@iplink.net Mon Jan 21 12:45:00 2002 From: alvin@iplink.net (alvin) Date: Mon Jan 21 12:45:00 2002 Subject: [tulip] Auto-negoation problem(I think) Message-ID: <3C4C5363.30052293@iplink.net> I have a system with an onboard tulip card that when under moderate load like the nightly backup will stop talking to the netowrk. I have 2 others with the same configuration that have no problems (well that have shown up yet) I get the following message: eth0: Transmit timed out, status f0660000, SIA 000002c0 ffff0001 fffbff7f 8ffdc008, restarting NWay . If I down and up the network the interface will start talking again. I do not have to unload the module. Where should I start looking for my problems. -- Alvin Starr || voice: (416)785-4051 Interlink Connectivity || fax: (416)785-3668 alvin@iplink.net || From shost@intellimec.com Tue Jan 22 01:09:01 2002 From: shost@intellimec.com (Steve Host) Date: Tue Jan 22 01:09:01 2002 Subject: [tulip] Bug in the current tulip driver: 0.9.15-pre9 (Nov 6, 2001) Message-ID: <005b01c1a30b$391db320$5009630a@intellimec.com> Greetings to all. I'm a long time tulip user, and happen to have many D-link De530's kicking around. A mandrake 8 box I have which has functioned perfectly started to misbehave when I upgraded to kernel 2.2.17 which uses tulip driver 0.9.15-pre9 (Nov 6, 2001). After banging my head for quite some time attempting to diagnose the problem at a high-level with fellow geeks from #linux on efnet IRC, i took a look at the actual hardware. To my dismay the problematic NIC was a revision AA 21041 chipset from Dec. I replaced it with a card revision PB chipset and the driver now functions correctly. This leads me to believe that 0.9.15-pre9 broke support for revision AA chipset cards, or perhaps more . If any of you require more information from me, don't hesatate to ask. I've replaced the board but could pop it back in temporarily to get any debug info you require. - Steve From pai@erise.hu Tue Jan 22 10:45:02 2002 From: pai@erise.hu (PAZINCZAR Peter) Date: Tue Jan 22 10:45:02 2002 Subject: [tulip] problems with accton en2242 Message-ID: Hi! I have a problem with the card called Accton EN2242 MiniPCI (recognized as ADMtek comet (rev 17) by tulip). I'm using the kernel v. 2.4.17 (debian/linux). The notebook is a Gericom stuff. First of all, on boot time the card got an IRQ 0. I`ve solved this problem setting the IRQ by setpci -s 00:05.0 interrupt_line=0a (03 also tried), `cos there were no possibility to set it in the PCI BIOS. After reboot it worked with the new IRQ. The kernels module passed, eth0 seemed to work fine. After this came some problems. The output of tulip-diag is: p-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Assuming a Digital Tulip series adapter at 0x1c00. 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 threshold is 128. Interrupt sources are pending! CSR5 is fc07c017. Tx done indication. Tx complete indication. Tx out of buffers indication. Link passed indication. Early Rx indication. EEPROM 256 words, 8 address bits. A simplifed EEPROM data table was found. The EEPROM does not contain transceiver control information. EEPROM contents (256 words): 0x00: 0985 0002 0000 0000 9000 1d96 9ff5 0000 0x08: 0000 0400 0001 0000 0000 0000 0000 0100 0x10: 1216 1113 2242 1113 ffff 0000 0000 a04c 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 cf0a . . . the rest are all zeros. ID block CRC 0x21 (vs. 00). Full contents CRC 0xcf0a (read as 0xcf0a). If i send a packet over eth0 (ifconfig output seems to be normal), i get the following: Jan 21 21:54:19 xxx kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 21 21:54:19 xxx kernel: eth0: Transmit timed out, status fc67c017, CSR12 00000000, resetting... Sure, because the eeprom contains no controll information. As i read on the tulip website, there are some other ways to define them in the module source. But, i don`t know how to get the values to set, and how to set them? ( :) ). Or is there any other way by writing the eeprom whith some controll information (as i did with IRQ before)? Could sy help me in this? Thx, {pai} From hmccaskey@worldnet.att.net Tue Jan 22 21:24:00 2002 From: hmccaskey@worldnet.att.net (Hal McCaskey) Date: Tue Jan 22 21:24:00 2002 Subject: [tulip] This chip has not been assigned a valid IRQ Message-ID: <001601c1a3b4$dcec50c0$ad492042@den> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C1A388.F33E2320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am loading Debian 2.2 rev 4 over Win98 in an HP PC with a Linksys = Network Anywhere 10/100 Card. Actually an AMDtek chip. =20 I used the tulip driver tthat came on the Debian CD.=20 tulip-diag -e output below tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-P adapter at 0x1400. 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. See http://www.scyld.com/expert/irq-conflict.html for more = information. Comet duplex is reported in the MII status registers. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. Comet MAC address registers 475a0400 ffff5e72 Comet multicast filter 0000000000000000. EEPROM 256 words, 8 address bits. Ethernet MAC Station Address 00:04:5a:47:72:5e. Default connection type 'Autosense'. PCI IDs Vendor 1317 Device 0985 Subsystem 1317 0570 PCI min_grant 255 max_latency 255. CSR18 power-up setting 0xa04c****. Any idea of what to do next? I don't see an option to set the IRQ via = BIOS I have all the settings ( IRQ 9) that worked with Win98. Seriously considering buying another networking card - Tired of fighting = with this on - .any suggestion on which one to buy? Thanks Hal McCaskey hmccaskey@att.net=20 ------=_NextPart_000_0011_01C1A388.F33E2320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 I am loading Debian 2.2 rev 4 over Win98 = in an=20 HP PC with a Linksys Network Anywhere 10/100 Card. Actually an AMDtek = chip.=20  
I used the tulip driver tthat came on the Debian CD.=20

tulip-diag  -e      output=20 below

tulip-diag.c:v2.08 5/15/2001 Donald Becker=20 (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index= #1:=20 Found a ADMtek AL985 Centaur-P adapter at 0x1400.
This chip has not = been=20 assigned a valid IRQ, and will not function.
 This must be fixed = in the=20 PCI BIOS setup.  The device driver has no way
 of changing = the PCI=20 IRQ settings.
 See =20 http://www.scyld.com/expert/irq-conflict.html  for more=20 information.
 Comet duplex is reported in the MII status=20 registers.
 Transmit stopped, Receive stopped, = half-duplex.
 =20 The Rx process state is 'Stopped'.
  The Tx process state is=20 'Stopped'.
  The transmit threshold is 128.
  Comet MAC = address=20 registers 475a0400 ffff5e72
  Comet multicast filter=20 0000000000000000.
EEPROM 256 words, 8 address bits.
  = Ethernet MAC=20 Station Address 00:04:5a:47:72:5e.
  Default connection type=20 'Autosense'.
  PCI IDs Vendor 1317 Device 0985  Subsystem = 1317=20 0570
  PCI min_grant 255 max_latency 255.
  CSR18 = power-up=20 setting 0xa04c****.

Any idea of what to do next?  I don't = see an=20 option to set the IRQ via BIOS

I have all the settings ( IRQ 9)=20  that worked with Win98.

Seriously considering buying = another=20 networking card - Tired of fighting with this on - .any suggestion on = which one=20 to buy?

Thanks
Hal McCaskey
hmccaskey@att.net =
------=_NextPart_000_0011_01C1A388.F33E2320-- From becker@scyld.com Wed Jan 23 12:51:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jan 23 12:51:01 2002 Subject: [tulip] problems with accton en2242 In-Reply-To: Message-ID: On Tue, 22 Jan 2002, PAZINCZAR Peter wrote: > I have a problem with the card called Accton EN2242 MiniPCI (recognized as > ADMtek comet (rev 17) by tulip). > I'm using the kernel v. 2.4.17 (debian/linux). The notebook is a Gericom > stuff. First of all, on boot time the card got an IRQ 0. I`ve solved this > problem setting the IRQ by setpci -s 00:05.0 interrupt_line=0a (03 also > tried), `cos there were no possibility to set it in the PCI BIOS. You haven't solved the problem. You still are not getting interrupts from the card. > After > reboot it worked with the new IRQ. The kernels module passed, eth0 seemed > to work fine. After this came some problems. > > The output of tulip-diag is: ... > Interrupt sources are pending! CSR5 is fc07c017. > Tx done indication. > Tx complete indication. > Tx out of buffers indication. > Link passed indication. Yup, the chip is raising an interrupt, but no one is listening. > If i send a packet over eth0 (ifconfig output seems to be normal), i get > the following: > Jan 21 21:54:19 xxx kernel: NETDEV WATCHDOG: eth0: transmit timed out > Jan 21 21:54:19 xxx kernel: eth0: Transmit timed out, status fc67c017, > CSR12 00000000, resetting... ...And this confirms it. This problem is no a Tulip driver issue. The problem is the interrupt mapping. You should ask about it on the kernel mailing list. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Wed Jan 23 12:55:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jan 23 12:55:01 2002 Subject: [tulip] This chip has not been assigned a valid IRQ In-Reply-To: <001601c1a3b4$dcec50c0$ad492042@den> Message-ID: On Tue, 22 Jan 2002, Hal McCaskey wrote: > I am loading Debian 2.2 rev 4 over Win98 in an HP PC with a Linksys > Network Anywhere 10/100 Card. Actually an AMDtek chip. > I used the tulip driver tthat came on the Debian CD. > > tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a ADMtek AL985 Centaur-P adapter at 0x1400. > 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. > See http://www.scyld.com/expert/irq-conflict.html for more information. ... > Any idea of what to do next? I don't see an option to set the IRQ via BIOS Have you read the web page? > Seriously considering buying another networking card - Tired of > fighting with this on - .any suggestion on which one to buy? The new card will have the same problem... it's a problem with the BIOS settings, not the card. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From heather@pti-inc.com Wed Jan 23 17:53:01 2002 From: heather@pti-inc.com (Heather Wilson) Date: Wed Jan 23 17:53:01 2002 Subject: [tulip] Adv: Semiconductor Training Short Courses Message-ID: <200201232252.RAA21327@philotas.hosting.swbell.net> PTI Seminars is presenting the following courses for semiconductor personnel.... For more details call 636-343-1333 and ask for Heather Wilson. ABCs of IC DESIGN & FABRICATION - Presented by: Denny Frye http://www.pti-inc.com/courses/icdesignfab.html February 20, 2002 San Jose, CA March 11, 2002 Portland, OR March 18, 2002 Singapore April 9, 2002 Boston, MA April 19, 2002 Munich, Germany April 30, 2002 Phoenix, AZ This course describes in simple terms a sequential format of information that constitutes the major fabrication processes and design for integrated devices. This one (1) day seminar gives you a comprehensive overview of the semiconductor industry & technology. The course will give you the background you need to understand the basics of semiconductor devices, how they work, the processing technologies & equipment to produce them, and circuit design techniques. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ABCs of BASIC ELECTRONICS AND DEVICES http://www.pti-inc.com/courses/basicmain.html March 18, 2002 San Jose, CA ADVANCED TOPICS IN CMP Chemical Mechanical Planarization http://www.pti-inc.com/coursesadvanced/advancedcmp.html March 21-22, 2002 San Jose, CA DEFECT ISOLATION for MULTI LEVEL FAILURE ANALYSIS http://www.pti-inc.com/courses/defectisolation.html March 25-26, 2002 San Jose, CA DEVICE PHYSICS MADE EASY http://www.pti-inc.com/courses/physics.html April 8, 2002 San Jose, CA Fundamentals of CHEMICAL MECHANICAL PROCESSING Presented by: Srini Raghavan http://www.pti-inc.com/courses/cmpmain.html March 6, 2002 San Jose, CA Fundamentals of CHEMICAL VAPOR DEPOSITION http://www.pti-inc.com/courses/cvdmain.html April 3, 2002 San Jose, CA Fundamentals of ION IMPLANTATION http://www.pti-inc.com/courses/ionmain.html April 2, 2002 San Jose, CA Fundamentals of MEMS DESIGN & FABRICATION http://www.pti-inc.com/coursesadvanced/memsic.html April 10, 2002 San Jose, CA July 24, 2002 San Francisco, CA Fundamentals of METALLIZATION http://www.pti-inc.com/courses/metalmain.html April 4, 2002 San Jose, CA Fundamental RF Plasma Generation for Semiconductor Equipment http://www.pti-inc.com/courses/rfequipment.html April 4, 2002 San Jose, CA July 24-25, 2002 San Francisco, CA Fundamentals of WET & DRY ETCH http://www.pti-inc.com/courses/etchmain.html March 7, 2002 San Jose, CA Fundamentals of PHOTOLITHOGRAPHY http://www.pti-inc.com/courses/photomain.html March 19, 2002 San Jose, CA Fundamentals of THERMAL PROCESSING http://www.pti-inc.com/courses/diffmain.html March 12, 2002 San Jose, CA INTELLECTUAL PROPERTY STRATEGIES for SEMICONDUCTOR INDUSTRY COMPANIES http://www.pti-inc.com/courses/intellectual.html February 18-19, 2002 San Jose, CA July 24-25, 2002 San Francisco, CA Intro to CMOS LAYOUT http://www.pti-inc.com/courses/cmos.html May 6-7, 2002 San Jose, CA Intro to DIGITAL SIGNAL PROCESSING http://www.pti-inc.com/coursesadvanced/dsp.html April 24-26, 2002 San Jose, CA Intro to MICRO CONTAMINATION CONTROL http://www.pti-inc.com/courses/contamain.html March 21, 2002 San Jose, CA Intro to Optical MEMS for Bio Sensing and Communications http://www.pti-inc.com/courses/mems.html April 11, 2002 San Jose, CA Intro to INTEGRATED YIELD MANAGEMENT http://www.pti-inc.com/coursesadvanced/yieldmanagement.html March 4-5, 2002 San Jose, CA April 18-19, 2002 Munich, Germany May 6-7, 2002 Singapore Intro to STATISTICAL PROCESSING CONTROL (SPC) http://www.pti-inc.com/courses/spc.html April 9, 2002 San Jose, CA LOW COST FLIP CHIP & WLCSP TECHNOLOGIES http://www.pti-inc.com/courses/flipchip.html April 8, 2002 San Jose, CA April 15, 2002 Munich, Germany May 9, 2002 Singapore July 19, 2002 San Francisco, CA PRODUCT MARKETING for the Semiconductor Industry http://www.pti-inc.com/courses/productmarketing.html February 27, 2002 San Jose, CA April 18, 2002 Munich, Germany RF WIRELESS FUNDAMENTALS http://www.pti-inc.com/courses/rfwireless.html February 25-26, 2002 San Jose, CA CHECK OUR WEB SITE FOR ADDITIONAL COURSES !! http://www.ptiseminars.com For a FULL TRAINING SCHEDULE of "open" course dates visit http://www.pti-inc.com/schedule.htm TO REGISTER Go To https://secure.hosting.swbell.net/www.pti-inc.com/registration.html TO SPEAK: * to an account manager about ATTENDING these courses or having them ONSITE contact us at (636) 343-1333 in the USA. Ask for HEATHER WILSON. * Fax (636) 343-8642 * Email: heather@pti-inc.com PTI SEMINARS, INC. "We Exceed Your Expectations!" * To unsubscribe please reply to heather@pti-inc.com and in the subject "Unsubscribe". We apologize for any inconvenience. From proski@gnu.org Wed Jan 23 19:08:01 2002 From: proski@gnu.org (Pavel Roskin) Date: Wed Jan 23 19:08:01 2002 Subject: [tulip] [PATCH] making old Conexant driver work Message-ID: Hello! Sorry for the crosspost to so many people and lists - I don't know who is subscribed to what and which lists are alive. Please trim To: and Cc: accordingly. I'm trying to add Linux support for Zoom PCI Cable Modem model 5001. Zoom distributes closed source drivers at http://www.zoomtel.com/cable/linuxdrivers.shtml The latest kernel they support is 2.4.4. I stronly believe that using closed source drivers is not a good idea, especially if it forces downgrading the kernel. Zoom PCI Cable Modem model 5001 consists essentially of two devices on one board - an ethernet interface on the RS7112 (aka CN7112) chip and a cable modem on the CN9414 chip. Both chips are produuced by Conexant. It appears that having a working driver for the RS7112 chip is sufficient - the cable modem appears as an external device connected to the ethernet port. Search on the web shows that the support for Conexant existed in the Tulip driver in the past, but was removed later. As Donald Becker writes on http://www.geocrawler.com/archives/3/425/2001/11/0/7170033/ , "The divergent Tulip driver distributed with the 2.4 kernels never really supported the Conexant chip". However, there is a thread starting here http://www.tux.org/hypermail/linux-tulip/2001-Jul/0054.html , in which Kent Hunt says that Conexant LANfinity is actually working for him. Further in the thread, at http://www.tux.org/hypermail/linux-tulip/2001-Jul/0077.html , Christoph Lameter publishes a tarball containing the driver supporting Conexant LANfinity. I took the driver and compiled in it under Linux-2.4.18-pre6, and it worked! I could use the cable modem without any problems. I only had to make some changes for compatibility with the modern kernels, that I'm attaching to this message. The changes are: 1) APM support didn't compile. Modern API is very different. I disabled APM support because fixing it would take hours of my time (I'm not a hard-core kernel hacker), and because the right thing is to fix the modern driver to support Conexant, not to fix this driver which is not even using modern PCI API. 2) request_region and release_region are redefined to use memory if momory I/O is used. In fact, request_region used to fail, and release_region reported and error to the syslog. Now request_region actually allocates the memory. 3) linux/slab.h used instead of linux/malloc.h to fix a warning 4) MODULE_LICENSE added. 5) "make install" is supported now. Not guaranteed to be correct if compiling for the kernel which is now running now, but still convenient and safer that copying by hand. ===================================== --- Makefile +++ Makefile @@ -2,6 +2,7 @@ OPTIONSCOMMON = -D__KERNEL__ -DMODULE -Wall -Wstrict-prototypes -O2 -I/usr/src/linux/include -fomit-frame-pointer -fno-strict-aliasing -Wno-trigraphs -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h OPTIONSTULIP = $(OPTIONSCOMMON) OPTIONSPCISN = $(OPTIONSCOMMON) -DEXPORT_SYMTAB +MODULE_INSTDIR = /lib/modules/`uname -r`/kernel/drivers//net/tulip/ all: $(CC) $(OPTIONSTULIP) -c tulip.c @@ -9,3 +10,8 @@ clean: rm -f *~ pci-scan.o tulip.o + +install: + install -d $(MODULE_INSTDIR) + install -m 644 pci-scan.o tulip.o $(MODULE_INSTDIR) + /sbin/depmod --- pci-scan.c +++ pci-scan.c @@ -62,10 +62,11 @@ static int min_pci_latency = 32; #include #include #include -#include +#include #include #include "pci-scan.h" #include "kern_compat.h" +#undef CONFIG_APM #ifdef CONFIG_APM #include #endif @@ -82,6 +83,7 @@ char kernel_version[] = UTS_RELEASE; int (*register_cb_hook)(struct drv_id_info *did); void (*unregister_cb_hook)(struct drv_id_info *did); +MODULE_LICENSE("GPL"); #if LINUX_VERSION_CODE > 0x20118 && defined(MODULE) MODULE_PARM(debug, "i"); MODULE_PARM(min_pci_latency, "i"); --- tulip.c +++ tulip.c @@ -145,7 +145,7 @@ static int csr0 = 0x00A00000 | 0x4800; #include #include #include -#include +#include #include #include #include @@ -172,6 +172,7 @@ char kernel_version[] = UTS_RELEASE; MODULE_AUTHOR("Donald Becker "); MODULE_DESCRIPTION("Digital 21*4* Tulip ethernet driver"); +MODULE_LICENSE("GPL"); MODULE_PARM(debug, "i"); MODULE_PARM(max_interrupt_work, "i"); MODULE_PARM(reverse_probe, "i"); @@ -198,6 +199,8 @@ MODULE_PARM(full_duplex, "1-" __MODULE_S #define outb writeb #define outw writew #define outl writel +#define request_region(start,n,name) request_mem_region(start,n,name) +#define release_region(start,n) release_mem_region(start,n) #endif /* ===================================== Christoph, please update the driver. Whether Conexant wants us to support their chips or not, there is a working open-source driver for RS7112, so their reluctance is no excuse (IMHO) and it's time to add it's support to the modern driver. I have made some changes to it, but it doesn't work so far. It cannot find EEPROM and doesn't detect the MAC address correctly: eth1: Conexant LANfinity rev 8 at 0xac00, EEPROM not present, 00:4C:69:6E:75:79, IRQ 11. 00:4C:69:6E:75:79 is "\000Linux" This patch is a work in progress. I'm going to work on in tomorrow, but I'm posting it here just in case, maybe somebody has a working driver already or can help me finish this patch. The patch is against Linux 2.4.18-pre6. ===================================== --- tulip_core.c +++ tulip_core.c @@ -188,6 +188,10 @@ struct tulip_chip_table tulip_tbl[] = { { "Davicom DM9102/DM9102A", 128, 0x0001ebef, HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI, tulip_timer }, + + /* RS7112 */ + { "Conexant LANfinity", 256, 0x0001ebef, + HAS_MII | HAS_ACPI, tulip_timer }, }; @@ -216,6 +220,7 @@ static struct pci_device_id tulip_pci_tb { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 }, { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, + { 0x14f1, 0x1803, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CONEXANT }, { } /* terminate list */ }; MODULE_DEVICE_TABLE(pci, tulip_pci_tbl); @@ -448,7 +453,7 @@ media_picked: tp->csr6 = 0x01a80200; outl(0x0f370000 | inw(ioaddr + 0x80), ioaddr + 0x80); outl(0x11000 | inw(ioaddr + 0xa0), ioaddr + 0xa0); - } else if (tp->chip_id == COMET) { + } else if (tp->chip_id == COMET || tp->chip_id == CONEXANT) { /* Enable automatic Tx underrun recovery. */ outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88); dev->if_port = tp->mii_cnt ? 11 : 0; @@ -1583,7 +1588,12 @@ static int __devinit tulip_init_one (str for (i = 0; i < 8; i ++) if (ee_data[i] != ee_data[16+i]) sa_offset = 20; - if (ee_data[0] == 0xff && ee_data[1] == 0xff && ee_data[2] == 0) { + if (chip_idx == CONEXANT) { + /* Check that the tuple type and length is correct. */ + if (ee_data[0x198] == 0x04 && ee_data[0x199] == 6) + sa_offset = 0x19A; + } else if (ee_data[0] == 0xff && ee_data[1] == 0xff && + ee_data[2] == 0) { sa_offset = 2; /* Grrr, damn Matrox boards. */ multiport_cnt = 4; } --- tulip.h +++ tulip.h @@ -84,6 +84,7 @@ COMPEX9881, I21145, DM910X, + CONEXANT, }; ===================================== -- Regards, Pavel Roskin From becker@scyld.com Wed Jan 23 19:15:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jan 23 19:15:00 2002 Subject: [tulip] Re: [PATCH] making old Conexant driver work In-Reply-To: Message-ID: On Wed, 23 Jan 2002, Pavel Roskin wrote: > Sorry for the crosspost to so many people and lists - I don't know who is > subscribed to what and which lists are alive. Please trim To: and Cc: > accordingly. > > I'm trying to add Linux support for Zoom PCI Cable Modem model 5001. > Zoom distributes closed source drivers at > http://www.zoomtel.com/cable/linuxdrivers.shtml Hmmm, those are not "closed source" drivers. They are, plain and simple, copyright violations. That is tulip.c with the identification removed. > Search on the web shows that the support for Conexant existed in the Tulip > driver in the past, but was removed later. Conexant support exists in my driver, but not the driver branch distributed with the kernel. > Further in the thread, at > http://www.tux.org/hypermail/linux-tulip/2001-Jul/0077.html , Christoph > Lameter publishes a tarball containing the driver supporting Conexant > LANfinity. This is just a (now slightly old) version of my driver, with a Makefile for a few new distributions. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From mdchaney@michaelchaney.com Wed Jan 23 20:03:01 2002 From: mdchaney@michaelchaney.com (Michael Chaney) Date: Wed Jan 23 20:03:01 2002 Subject: [tulip] This chip has not been assigned a valid IRQ In-Reply-To: <001601c1a3b4$dcec50c0$ad492042@den>; from hmccaskey@worldnet.att.net on Tue, Jan 22, 2002 at 09:08:33PM -0500 References: <001601c1a3b4$dcec50c0$ad492042@den> Message-ID: <20020123190555.A6646@michaelchaney.com> On Tue, Jan 22, 2002 at 09:08:33PM -0500, Hal McCaskey wrote: > Any idea of what to do next? I don't see an option to set the IRQ via > BIOS Shot in the dark, but in your BIOS setup it will have an option for "plug and play os", set it to "no". It should be set to "no" for all os's except perhaps win3.x. Michael -- Michael Darrin Chaney mdchaney@michaelchaney.com http://www.michaelchaney.com/ From proski@gnu.org Wed Jan 23 20:08:01 2002 From: proski@gnu.org (Pavel Roskin) Date: Wed Jan 23 20:08:01 2002 Subject: [tulip] Re: [PATCH] making old Conexant driver work In-Reply-To: Message-ID: Hi, Donald! I'm impressed how fast you managed to reply me :-) > > Search on the web shows that the support for Conexant existed in the Tulip > > driver in the past, but was removed later. > > Conexant support exists in my driver, but not the driver branch > distributed with the kernel. I'm sorry, but I probably cannot find the driver you mean. This is what I have looked so far. 1) The drivers at http://www.scyld.com/network/tulip-devel.html Both the "standard release" and the "test version" have internal version 0.93. Both support Conexant LANfinity. Both are using the custom PCI support instead of the kernel PCI API. It appears that both drivers are from the same "old generation". They also (wrongly IMHO) use requiest_region even if USE_IO_OPS is undefined. 2) The driver from the source RPM on http://www.scyld.com/network/updates.html This is even older - it's v0.92x. The same comments apply. 3) Drivers from http://sourceforge.net/projects/tulip/ Neither the stable nor the development versions include support for Conexant LANfinity except in the diagnostics utility. I'm sorry, but this reminds a madhouse. I admit that I don't have the full picture, I don't know if you can update those pages, I don't know whether Conexant threatens you. But I believe that nobody can prevent you from adding a notice to the driver included into the kernel that it has been deliberately crippled as a result of something beyond your control. Even if you don't control any of the sites I mentioned above, I'm sure that Linus and Alan will gladly apply a patch with such notice to the kernel. I don't think that anybody can force you and Jeff Garzik to say that Conexant LANfinity is not supported because of insufficient documentation (see http://sourceforge.net/mailarchive/forum.php?thread_id=150363&forum_id=3720) Something must be very wrong here :-( -- Best regards, Pavel Roskin From hmccaskey@worldnet.att.net Wed Jan 23 20:10:00 2002 From: hmccaskey@worldnet.att.net (Hal McCaskey) Date: Wed Jan 23 20:10:00 2002 Subject: [tulip] This chip has not been assigned a valid IRQ Message-ID: <002f01c1a473$cd661c20$ad492042@den> This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C1A449.E159A140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My sincere thanks. It's working now! In my haste to find an option for setting the IRQ via Lilo, I completely = read over the HP paragraph about the BIOS setup. I actully read it and = did not make the connection. Duh! Thanks for the courteous and prompt response. Hal McCaskey=20 ------=_NextPart_000_0028_01C1A449.E159A140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 My sincere thanks.  It's working=20 now!

In my haste to find an option for setting the IRQ via Lilo, = I=20 completely read over the HP paragraph about the BIOS setup.  I = actully read=20 it and did not make the connection. Duh!

Thanks for the courteous = and=20 prompt response.

Hal McCaskey
------=_NextPart_000_0028_01C1A449.E159A140-- From jgarzik@mandrakesoft.com Wed Jan 23 20:22:00 2002 From: jgarzik@mandrakesoft.com (Jeff Garzik) Date: Wed Jan 23 20:22:00 2002 Subject: [tulip] Re: [PATCH] making old Conexant driver work References: Message-ID: <3C4F6189.44E937B0@mandrakesoft.com> If you send me a patch that you have tested, which gets Conexant working in 2.4 kernels, I'll apply it. -- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com From becker@scyld.com Wed Jan 23 20:46:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jan 23 20:46:00 2002 Subject: [tulip] Re: [PATCH] making old Conexant driver work In-Reply-To: Message-ID: On Wed, 23 Jan 2002, Pavel Roskin wrote: > > Conexant support exists in my driver, but not the driver branch > > distributed with the kernel. > > I'm sorry, but I probably cannot find the driver you mean. This is what I > have looked so far. > > 1) The drivers at http://www.scyld.com/network/tulip-devel.html > Both the "standard release" and the "test version" have internal version > 0.93. Both support Conexant LANfinity. Both are using the custom PCI > support instead of the kernel PCI API. It appears that both drivers are > from the same "old generation". > They also (wrongly IMHO) use > requiest_region even if USE_IO_OPS is undefined. This is to support the older kernels, where registering the memory region is better than not registering at all. > I'm sorry, but this reminds a madhouse. I admit that I don't have the > full picture, I don't know if you can update those pages, I don't know > whether Conexant threatens you. I've emailed Zoom the usual "fix it in seven days" letter. That should get us the source code to see if they set any of the configuration registers differently than I do. > I don't think that anybody can force you and Jeff Garzik to say that > Conexant LANfinity is not supported because of insufficient documentation > (see http://sourceforge.net/mailarchive/forum.php?thread_id=150363&forum_id=3720) I have the documentation, but it arrived in a plain brown wrapper. Conexant wouldn't give out anything but glossy brochures. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From proski@gnu.org Sat Jan 26 01:25:00 2002 From: proski@gnu.org (Pavel Roskin) Date: Sat Jan 26 01:25:00 2002 Subject: [tulip] mii taints kernel, big EEPROM patch, missing tulip.txt Message-ID: Hi, Jeff! In Linux-2.4.18-pre7, the module mii has no license. Also having a description would be nice. ========================== --- linux.orig/drivers/net/mii.c +++ linux/drivers/net/mii.c @@ -168,6 +168,10 @@ int mii_nway_restart (struct mii_if_info return r; } +MODULE_AUTHOR ("Jeff Garzik "); +MODULE_DESCRIPTION ("Kernel part of Ethtool"); +MODULE_LICENSE("GPL"); + EXPORT_SYMBOL(mii_link_ok); EXPORT_SYMBOL(mii_nway_restart); EXPORT_SYMBOL(mii_ethtool_gset); ========================== By the way, I have finally made a working driver for Conexant, but I didn't have time to send it from the office today and forgot to copy it to an external site. I'll send it on Monday. Basically it's the patch that I already sent, but with EEPROM_SIZE changed to 512. That's because RS7112 keeps the MAC address near the end of EEPROM. I feel uneasy that ee_data is now quite big for the stack (512 bytes) in tulip_init_one(), but it works. Why doesn't tulip_init_one() use tp->eeprom immediately? tp->eeprom is allocated in the kernel memory. Ok, I just made a patch that makes exactly that and will make it easier to increase EEPROM_SIZE. I tested it on my Linksys card, which is determined by the driver as eth0: ADMtek Comet rev 17 at 0xd800, 00:04:5A:43:9C:F0, IRQ 11. and listed by lspci as 00:08.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) This message will be sent through the patched driver :-) =========================== --- linux.orig/drivers/net/tulip/tulip_core.c +++ linux/drivers/net/tulip/tulip_core.c @@ -1354,7 +1354,6 @@ static int __devinit tulip_init_one (str u8 chip_rev; int i, irq; unsigned short sum; - u8 ee_data[EEPROM_SIZE]; struct net_device *dev; long ioaddr; static int board_idx = -1; @@ -1573,17 +1572,17 @@ static int __devinit tulip_init_one (str int sa_offset = 0; int ee_addr_size = tulip_read_eeprom(ioaddr, 0xff, 8) & 0x40000 ? 8 : 6; - for (i = 0; i < sizeof(ee_data)/2; i++) - ((u16 *)ee_data)[i] = + for (i = 0; i < sizeof(tp->eeprom)/2; i++) + ((u16 *)tp->eeprom)[i] = le16_to_cpu(tulip_read_eeprom(ioaddr, i, ee_addr_size)); /* DEC now has a specification (see Notes) but early board makers just put the address in the first EEPROM locations. */ /* This does memcmp(eedata, eedata+16, 8) */ for (i = 0; i < 8; i ++) - if (ee_data[i] != ee_data[16+i]) + if (tp->eeprom[i] != tp->eeprom[16+i]) sa_offset = 20; - if (ee_data[0] == 0xff && ee_data[1] == 0xff && ee_data[2] == 0) { + if (tp->eeprom[0] == 0xff && tp->eeprom[1] == 0xff && tp->eeprom[2] == 0) { sa_offset = 2; /* Grrr, damn Matrox boards. */ multiport_cnt = 4; } @@ -1604,8 +1603,8 @@ static int __devinit tulip_init_one (str } #endif for (i = 0; i < 6; i ++) { - dev->dev_addr[i] = ee_data[i + sa_offset]; - sum += ee_data[i + sa_offset]; + dev->dev_addr[i] = tp->eeprom[i + sa_offset]; + sum += tp->eeprom[i + sa_offset]; } } /* Lite-On boards have the address byte-swapped. */ @@ -1676,8 +1675,6 @@ static int __devinit tulip_init_one (str } if (tp->flags & HAS_MEDIA_TABLE) { - memcpy(tp->eeprom, ee_data, sizeof(tp->eeprom)); - sprintf(dev->name, "tulip%d", board_idx); /* hack */ tulip_parse_eeprom(dev); strcpy(dev->name, "eth%d"); /* un-hack */ =========================== The last thing. Documentation/networking/00-INDEX in Linux-2.4.18-pre7 mentions tulip.txt, but there is no such file in the kernel sources. Please add it if you have it. -- Regards, Pavel Roskin From al593181@mail.mty.itesm.mx Mon Jan 28 12:10:09 2002 From: al593181@mail.mty.itesm.mx (Felipe Contreras) Date: Mon Jan 28 12:10:09 2002 Subject: [tulip] Pavel Roskin Message-ID: <20020128170724.GA23159@sion.mty.itesm.mx> --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I can report that the Pavel Roskin patch works fine, it's exacly like the tulip 0.93 but truly for 2.4.x. I've always had an error with pc nic card (Davicom) and the cross-cable, I hope this new driver doesn't ping me out of irc when I compile stuff, anyway I'm sending this with it ;) I'm sending the patch against a 2.5.2-dj6 kernel. -- Felipe Contreras --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tulip.diff" diff -ur tulip.bak/tulip.h tulip/tulip.h --- tulip.bak/tulip.h Sun Jan 27 02:33:48 2002 +++ tulip/tulip.h Mon Jan 28 01:50:53 2002 @@ -84,6 +84,7 @@ COMPEX9881, I21145, DM910X, + CONEXANT, }; diff -ur tulip.bak/tulip_core.c tulip/tulip_core.c --- tulip.bak/tulip_core.c Sun Jan 27 02:17:44 2002 +++ tulip/tulip_core.c Mon Jan 28 01:57:27 2002 @@ -185,6 +185,11 @@ { "Davicom DM9102/DM9102A", 128, 0x0001ebef, HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI, tulip_timer }, + + /* RS7112 */ + { "Conexant LANfinity", 256, 0x0001ebef, + HAS_MII | HAS_ACPI, tulip_timer }, + }; @@ -209,6 +214,7 @@ { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X }, { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, + { 0x14f1, 0x1803, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CONEXANT }, { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 }, { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, { } /* terminate list */ @@ -417,7 +423,7 @@ tp->csr6 = 0x01a80200; outl(0x0f370000 | inw(ioaddr + 0x80), ioaddr + 0x80); outl(0x11000 | inw(ioaddr + 0xa0), ioaddr + 0xa0); - } else if (tp->chip_id == COMET) { + } else if (tp->chip_id == COMET || tp->chip_id == CONEXANT) { /* Enable automatic Tx underrun recovery. */ outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88); dev->if_port = tp->mii_cnt ? 11 : 0; @@ -1251,7 +1257,6 @@ u8 chip_rev; int i, irq; unsigned short sum; - u8 ee_data[EEPROM_SIZE]; struct net_device *dev; long ioaddr; static int board_idx = -1; @@ -1450,17 +1455,21 @@ int sa_offset = 0; int ee_addr_size = tulip_read_eeprom(ioaddr, 0xff, 8) & 0x40000 ? 8 : 6; - for (i = 0; i < sizeof(ee_data)/2; i++) - ((u16 *)ee_data)[i] = + for (i = 0; i < sizeof(tp->eeprom)/2; i++) + ((u16 *)tp->eeprom)[i] = le16_to_cpu(tulip_read_eeprom(ioaddr, i, ee_addr_size)); /* DEC now has a specification (see Notes) but early board makers just put the address in the first EEPROM locations. */ /* This does memcmp(eedata, eedata+16, 8) */ for (i = 0; i < 8; i ++) - if (ee_data[i] != ee_data[16+i]) + if (tp->eeprom[i] != tp->eeprom[16+i]) sa_offset = 20; - if (ee_data[0] == 0xff && ee_data[1] == 0xff && ee_data[2] == 0) { + if (chip_idx == CONEXANT) { + /* Check that the tuple type and length is correct. */ + if (tp->eeprom[0x198] == 0x04 && tp->eeprom[0x199] == 6) + sa_offset = 0x19A; + } else if (tp->eeprom[0] == 0xff && tp->eeprom[1] == 0xff && tp->eeprom[2] == 0) { sa_offset = 2; /* Grrr, damn Matrox boards. */ multiport_cnt = 4; } @@ -1481,8 +1490,8 @@ } #endif for (i = 0; i < 6; i ++) { - dev->dev_addr[i] = ee_data[i + sa_offset]; - sum += ee_data[i + sa_offset]; + dev->dev_addr[i] = tp->eeprom[i + sa_offset]; + sum += tp->eeprom[i + sa_offset]; } } /* Lite-On boards have the address byte-swapped. */ @@ -1553,8 +1562,6 @@ } if (tp->flags & HAS_MEDIA_TABLE) { - memcpy(tp->eeprom, ee_data, sizeof(tp->eeprom)); - sprintf(dev->name, "tulip%d", board_idx); /* hack */ tulip_parse_eeprom(dev); strcpy(dev->name, "eth%d"); /* un-hack */ --YiEDa0DAkWCtVeE4-- From joel_driverfr@yahoo.fr Tue Jan 29 09:33:01 2002 From: joel_driverfr@yahoo.fr (=?iso-8859-1?q?Joel=20Cordonnier?=) Date: Tue Jan 29 09:33:01 2002 Subject: [tulip] Accton EN2242 / kernel-2.4.15 / HP omnibook XE3 Message-ID: <20020129143217.59083.qmail@web13005.mail.yahoo.com> Hi ! I download and follow the instructions to compile and install the Tulip network driver. But I have the following problem: when i execute 'insmod pci-scan.o' no problem, BUT when i execute 'insmod tulip.o' my shell block and my compute hang ! :-( Do you have experience of such a problem ? Thanks a lot /Joel Suse 7.3 distribution of a HP omnibook XE3 updated with kernel-2.4.15 gcc v 2.95.c /Suse insmod v 2.4.8 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr From pgs@sobalvarro.org Wed Jan 30 00:41:01 2002 From: pgs@sobalvarro.org (Patrick G. Sobalvarro) Date: Wed Jan 30 00:41:01 2002 Subject: [tulip] need effective procedure for using tulip driver under RedHat 7.2 Message-ID: <000401c1a950$a147a730$0901a8c0@mabuse> I got the net driver package, compiled and installed under RH 7.2, and depmod -ae gives: pci-scan.o: unresolved symbol pci_write_config_byte pci-scan.o: unresolved symbol pci_find_class pci-scan.o: unresolved symbol pci_read_config_byte pci-scan.o: unresolved symbol pci_read_config_dword pci-scan.o: unresolved symbol __ioremap pci-scan.o: unresolved symbol pci_read_config_word pci-scan.o: unresolved symbol pci_set_master ...etc., with a similar list for tulip.o. I thought, the RH-shipped kernel is apparently not exporting these; I'll build my own. So I got the 2.4.17 sources off kernel.org, built a new kernel, installed it, compiled under it, got exactly the same errors from depmod -ae. I've search the tulip-bug archives, don't seem to be able to find a solution, although I see where other people have had the same problem. I presume I am doing something simple and wrong. Any insights? Thanks, Patrick From becker@scyld.com Wed Jan 30 19:24:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jan 30 19:24:01 2002 Subject: [tulip] need effective procedure for using tulip driver under RedHat 7.2 In-Reply-To: <000401c1a950$a147a730$0901a8c0@mabuse> Message-ID: On Wed, 30 Jan 2002, Patrick G. Sobalvarro wrote: > I got the net driver package, compiled and installed under RH 7.2, and > depmod -ae gives: Are you using the new source RPM? (netdrivers-3.1-1.src.rpm) > pci-scan.o: unresolved symbol pci_write_config_byte > pci-scan.o: unresolved symbol pci_find_class This looks like a module version problem. The usual source of the problem is pointing to the wrong include files. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From freehgh@hotmail.com Thu Jan 31 23:41:02 2002 From: freehgh@hotmail.com (freehgh@hotmail.com) Date: Thu Jan 31 23:41:02 2002 Subject: [tulip] Tired Of Dieting? Learn About HGH And Permanent Weight Loss! 1685432221 Message-ID: <200202010440.g114eHR11300@blueraja.scyld.com> As seen on NBC, CBS, CNN, and even Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has even been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed! * Permanent Weight Loss * Burn Excess Body Fat * More Energy * Increase Strength * Improve Sports/Exercise Performance * Natural Antidepressant * Restore Youthful Skin Elasticity * Increase Testosterone levels * Improve Sleep 1.Body Fat Loss 82% improvement. 2.Wrinkle Reduction 61% improvement. 3.Energy Level 84% improvement. 4.Muscle Strength 88% improvement. 5.Sexual Potency 75% improvement. 6.Emotional Stability 67% improvement. 7.Memory 62% improvement. 100% Satisfaction Guarantee,Free 1 Month Supply! And much, much more ... click here to get started: http://hgh.2hu.org or http://freehgh.81832.com Hello! Did you know that 10,000 Doctors and Health Care Professionals now believe that increasing levels of human growth hormone may facilitate permanent weight and body fat loss, better health, improve fitness, build muscle, increase energy, enhance sports and exercise performance, improve sleep, elevate mood, and so much more! "My energy level is fantastic, I now seem to be able to do so much more and not feel tired at all." John Camesi "It is 8 weeks later, I am now 25 pounds lighter, and have more energy then I have had in years." Robert Leaverton "I am 52 and was 20 lbs overweight. Well, I have already lost 10 lbs since I started the oral spray 11 weeks ago. I haven't felt this good in years. I was skeptical... but not anymore! I can't wait to lose more weight now!" John van den Broek "Also I noticed that my energy level is so high that even after a hard day of school I can't wait to get to the gym." Jenny Gallagher "The GH oral spray has really helped me gain muscle mass and burn off body fat. My endurance during my workouts is amazing!" Peter Kaplan These statements have not been evaluated by the Food and Drug Administration. This product is not intended to diagnose, treat, cure, mitigate or prevent any disease. Please consult with your doctor before beginning this or any dietary supplement program. You are receiving this email as a subscriber to the Opt-In America Mailing List. To remove yourself from all related maillists, just click here: http://remove.51road.com 1685432221