RE: [eepro100] Re: [vortex] True on TRANSMIT ERROR = TIMEOUT

gt3389b@mindspring.com<= /DIV> ------=_NextPart_000_000D_01BFE072.5CCD1160-- From tulip-admin@blueraja.scyld.com Wed Jun 28 01:58:22 2000 Received: from www.nameplanet.com (mail@www.nameplanet.com [212.125.173.44]) by blueraja.scyld.com (8.9.3/8.9.3) with SMTP id BAA07497 for ; Wed, 28 Jun 2000 01:58:18 -0400 From: thomas@wong.as Received: 28 Jun 2000 05:54:33 -0000 Message-ID: <20000628055433.11578.qmail@www.nameplanet.com> To: tulip@scyld.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [tulip] RE: Problem with LNE100TX (ver4.1) Date: Wed Jun 28 01:58:23 2000 Hi, I recently bought more than 10 pcs of LNE100TX (ver 4.1 this is printed on the card itself) and found that my RH6.2 doesn't recognize it. I try to compile the tulip.c (v0.92) and found that it return me this error after I do the "insmod tulip.o" >> unresolved symbol pci_drv_unregister >> unresolved symbol pci_drv_register I saw one posting and found that I need to compile pci-netif.c (gcc -DMODULE - D__KERNEL__ -O6 -c pci-netif.c). I compile it but now I received another error message from after doing the "insmod pci-netif.o" The error message is >> couldn't find the kernel version the module was compiled for What have I miss during the compilation ?? Secondly, when my system boot up the it show the below message for the PCI Device Listing: Bus No Device No ... Vendor ID Device ID ... IRQ 0 19 ... 1317 0985 ... 5 I did the source code for tulip.c and found that this vendor id and device id are referring to ADMtek Centaur-P. Anyone who has any idea how to solve this problem , please please please reply. I need help urgently. I bought this NIC card being fooled by the logo Tested with Linux on the box cover thinking that support and driver is given. What a mistake ? Regards, Thomas Wong -- Get your firstname@lastname email for FREE at http://NamePlanet.com From tulip-admin@blueraja.scyld.com Wed Jun 28 03:09:52 2000 Received: from mail5.lig.bellsouth.net (mail5.lig.bellsouth.net [205.152.0.12]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id DAA07843 for ; Wed, 28 Jun 2000 03:09:52 -0400 Received: from vortex.morris.net (adsl-78-168-161.hsv.bellsouth.net [216.78.168.161]) by mail5.lig.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id DAA24496; Wed, 28 Jun 2000 03:06:13 -0400 (EDT) Received: from Morris.net (speedy.morris.net [192.168.10.101]) by vortex.morris.net (8.9.3/8.8.7) with ESMTP id CAA16090; Wed, 28 Jun 2000 02:06:12 -0500 Message-ID: <3959A461.25E16B0D@Morris.net> From: Jim Morris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: thomas@wong.as CC: tulip@scyld.com Subject: Re: [tulip] RE: Problem with LNE100TX (ver4.1) References: <20000628055433.11578.qmail@www.nameplanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed Jun 28 03:09:53 2000 thomas@wong.as wrote: > Anyone who has any idea how to solve this problem , please please please reply. > I need help urgently. I bought this NIC card being fooled by the logo Tested > with Linux on the box cover thinking that support and driver is given. What a > mistake ? Unfortunately, Linksys seems to keep changing their card design, causing problems working with the standard Tulip driver. That said, the last few Linksys cards I bought (LNE100TX) included a tulip.c driver on the 2nd driver floppy that came with the card. That should work with Linux 2.0.x and 2.2.x kernels. I used to buy and recommend a lot of Linksys cards. I've stopped doing that, after running into so many problems with using the stock tulip driver. Most of the problems I've seen with the current card are related to media detection and negotiation. I.e. a Linksys card will work fine on a 10BaseT or 100BaseTX hub, but not connected to a 10/100 autoswitching hub or switch. Good luck... wish I could help more. -- /------------------------------------------------\ | Jim Morris | Business: jmorris@rtc-group.com | | | Personal: Jim@Morris.net | |------------------------------------------------| | AOL Instant Messenger: JFM2001 | \------------------------------------------------/ From tulip-admin@blueraja.scyld.com Wed Jun 28 10:07:53 2000 Received: from gem.lightlink.com (root@gem.lightlink.com [205.232.34.13]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id KAA09703 for ; Wed, 28 Jun 2000 10:07:53 -0400 Received: from adore.lightlink.com (homer@adore.lightlink.com [205.232.34.20]) by gem.lightlink.com (8.8.8/8.8.8) with ESMTP id KAA30745; Wed, 28 Jun 2000 10:04:09 -0400 From: Homer Wilson Smith To: thomas@wong.as cc: tulip@scyld.com Subject: Re: [tulip] RE: Problem with LNE100TX (ver4.1) In-Reply-To: <20000628055433.11578.qmail@www.nameplanet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed Jun 28 10:07:54 2000 > card itself) and found that my RH6.2 doesn't recognize it. I try to compile the > tulip.c (v0.92) and found that it return me this error after I do the "insmod > tulip.o" > >> unresolved symbol pci_drv_unregister > >> unresolved symbol pci_drv_register I think you are missing the pci-scan module. REad about it on the tulip home page. Homer > > I saw one posting and found that I need to compile pci-netif.c (gcc -DMODULE - > D__KERNEL__ -O6 -c pci-netif.c). I compile it but now I received another error > message from after doing the "insmod pci-netif.o" The error message is > >> couldn't find the kernel version the module was compiled for > > What have I miss during the compilation ?? > > Secondly, when my system boot up the it show the below message for the PCI > Device Listing: > > Bus No Device No ... Vendor ID Device ID ... IRQ > 0 19 ... 1317 0985 ... 5 > > I did the source code for tulip.c and found that this vendor id and device id > are referring to ADMtek Centaur-P. > > Anyone who has any idea how to solve this problem , please please please reply. > I need help urgently. I bought this NIC card being fooled by the logo Tested > with Linux on the box cover thinking that support and driver is given. What a > mistake ? > > Regards, > Thomas Wong > > > > -- > Get your firstname@lastname email for FREE at http://NamePlanet.com > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip > From tulip-admin@blueraja.scyld.com Wed Jun 28 12:03:37 2000 Received: from vaio.greennet (adsl-151-196-242-17.bellatlantic.net [151.196.242.17]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id MAA10797 for ; Wed, 28 Jun 2000 12:03:36 -0400 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id MAA01915; Wed, 28 Jun 2000 12:03:13 -0400 From: Donald Becker X-Sender: becker@vaio.greennet To: thomas@wong.as cc: tulip@scyld.com Subject: Re: [tulip] RE: Problem with LNE100TX (ver4.1) In-Reply-To: <20000628055433.11578.qmail@www.nameplanet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed Jun 28 12:03:37 2000 On 28 Jun 2000 thomas@wong.as wrote: > I recently bought more than 10 pcs of LNE100TX (ver 4.1 this is printed on the > card itself) and found that my RH6.2 doesn't recognize it. I try to compile the The v4.* boards use the ADMtek Comet/Centaur chip. The Tulip driver has supported this since August '99. The version in the kernel has diverged and not incorported the new support. > tulip.c (v0.92) and found that it return me this error after I do the "insmod > tulip.o" > >> unresolved symbol pci_drv_unregister > >> unresolved symbol pci_drv_register Read http://www.scyld.com/network/updates.html There is a Makefile, a .tgz file, and a SRPM to try to make this easier. > Bus No Device No ... Vendor ID Device ID ... IRQ > 0 19 ... 1317 0985 ... 5 Yup, an AN983 Centaur-C (nee AN985). Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations Annapolis MD 21403 From tulip-admin@blueraja.scyld.com Thu Jun 29 00:10:12 2000 Received: from www.nameplanet.com (mail@www.nameplanet.com [212.125.173.44]) by blueraja.scyld.com (8.9.3/8.9.3) with SMTP id AAA17982 for ; Thu, 29 Jun 2000 00:10:11 -0400 From: thomas@wong.as Received: 29 Jun 2000 04:06:27 -0000 Message-ID: <20000629040627.20703.qmail@www.nameplanet.com> To: becker@scyld.com Cc: tulip@scyld.com MIME-Version: 1.0 Subject: Re: [tulip] RE: Problem with LNE100TX (ver4.1) Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu Jun 29 00:10:12 2000 Hi, I tried using the SRPM but it still can't recognize/detect my network card. When I do insmod tulip.o, I still received the below message : >> unresolved symbol pci_drv_unregister >> unresolved symbol pci_drv_register I read through some mailing list that indicate that I need to compile pci- netif.c . Is this necessary ? If yes, what switch / option I need to set during the compilation using gcc ? By the way, do I need change any conf files ? Thanks very much for your help and your beowulf cluster is superb !!! Regards, Thomas On Wed, 28 Jun 2000 12:03:13 -0400 (EDT) Donald Becker wrote: >On 28 Jun 2000 thomas@wong.as wrote: > >> I recently bought more than 10 pcs of LNE100TX (ver 4.1 this is printed on the >> card itself) and found that my RH6.2 doesn't recognize it. I try to compile the > >The v4.* boards use the ADMtek Comet/Centaur chip. > >The Tulip driver has supported this since August '99. The version in >the kernel has diverged and not incorported the new support. > >> tulip.c (v0.92) and found that it return me this error after I do the "insmod >> tulip.o" >> >> unresolved symbol pci_drv_unregister >> >> unresolved symbol pci_drv_register > >Read > http://www.scyld.com/network/updates.html > >There is a Makefile, a .tgz file, and a SRPM to try to make this easier. > >> Bus No Device No ... Vendor ID Device ID ... IRQ >> 0 19 ... 1317 0985 ... 5 > >Yup, an AN983 Centaur-C (nee AN985). > >Donald Becker becker@scyld.com >Scyld Computing Corporation http://www.scyld.com >410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations >Annapolis MD 21403 > > > -- Get your firstname@lastname email for FREE at http://NamePlanet.com From tulip-admin@blueraja.scyld.com Fri Jun 30 17:45:13 2000 Received: from hotmail.com (f102.law3.hotmail.com [209.185.241.102]) by blueraja.scyld.com (8.9.3/8.9.3) with SMTP id RAA12080 for ; Fri, 30 Jun 2000 17:45:10 -0400 Received: (qmail 90805 invoked by uid 0); 30 Jun 2000 21:40:43 -0000 Message-ID: <20000630214043.90804.qmail@hotmail.com> Received: from 209.179.252.226 by www.hotmail.com with HTTP; Fri, 30 Jun 2000 14:40:43 PDT X-Originating-IP: [209.179.252.226] From: "Ute Jensen" To: tulip@scyld.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Subject: [tulip] unresolved symbols in Tulip build on SuSe (2.2.5 kernel) Date: Fri Jun 30 17:45:14 2000 Hola! I have a LinkSys Etherfast 10/100 (LNE100TX) Version 2 connected to a Netgear EN104TP Hub.. lights are green, all okay. I have SuSe Linux (6.1) with the 2.2.5 kernel. It came with a tulip module, but it didn't work (I forget what the errors were). So I came to scyld for the latest. I was unable to compile tulip.o by itself (again, I forget the errors, sorry), so I went for the netdrivers source RPM. After finding that SuSe keeps the packages in /usr/src/packages (rather than /usr/src/linux/packages) I was able to build and install just fine-- no errors at all in the log, except for this, which I think is irrelevant to me: install: cb_shim.o: No such file or directory make: [install] Error 1 (ignored) But just in case, I tried to build it by itself, but apparently there is a header file missing, which might be why it didn't build in the package? So anyway I proceeded to.. *** Run '/sbin/depmod -a' to update the module database. and this is what I get.. pan:/ # depmod -a depmod: *** Unresolved symbols in /lib/modules/2.2.5/net/tulip.o depmod: *** Unresolved symbols in /lib/modules/2.2.5/scsi/scsi_debug.o depmod: *** Unresolved symbols in /lib/modules/2.2.5/scsi/sd_mod.o depmod: *** Unresolved symbols in /lib/modules/2.2.5/video/vfb.o depmod: *** Unresolved symbols in /lib/modules/2.2.5/misc/maui.o depmod: *** Unresolved symbols in /lib/modules/2.2.5/pcmcia/iscc_cs.o depmod: *** Unresolved symbols in /lib/modules/2.2.5/pcmcia/mpsuni_cs.o Since tulip is all I care about right now.. pan:/ # insmod tulip Using /lib/modules/2.2.5/net/tulip.o /lib/modules/2.2.5/net/tulip.o: unresolved symbol __global_cli /lib/modules/2.2.5/net/tulip.o: unresolved symbol pci_drv_unregister /lib/modules/2.2.5/net/tulip.o: unresolved symbol __global_save_flags /lib/modules/2.2.5/net/tulip.o: unresolved symbol __global_restore_flags /lib/modules/2.2.5/net/tulip.o: unresolved symbol pci_drv_register Is the package not designed to build on SuSe or am I doing something wrong? In the code, I found that cli and save_flags are called in tulip.c, but in kern_compat.h where they are defined, they are commented out (and then only used with versions below Ox20123 (does 2.2.5 fall in that range?)). I didn't study tulip.c in detail (I'm not a programmer), but are these functions actually used? Just in case, since this used to be a problem, I checked if pci-scan was there. pan:/ # insmod pci-scan Using /lib/modules/2.2.5/net/pci-scan.o insmod: a module named pci-scan already exists It is. Well, I guess the modules won't load with unresolved symbols. But here are the results of everything else I tried just in case they would... So start the net.. pan:/ # /etc/rc.d/init.d/network start Setting up network device eth0 SIOCSIFADDR: Operation not supported by device eth0: unknown interface: Operation not supported by device SIOCSIFBRDADDR: Operation not supported by device eth0: unknown interface: Operation not supported by device SIOCSIFNETMASK: Operation not supported by device eth0: unknown interface: Operation not supported by device failed Try to configure the interface ? pan:/ # ifconfig eth0 192.168.1.2 SIOCSIFADDR: Operation not supported by device eth0: unknown interface: Operation not supported by device Can't do that; check module config. Looks ok. pan:/ # grep tulip /etc/conf.modules alias eth0 tulip # options tulip options=0 Make sure the hardware is okay at least pan:/ # lspci -vv ... 00:0e.0 Ethernet controller: Lite-On Communications Inc: Unknown device c115 (rev 25) Subsystem: Unknown device 11ad:c001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- ; Thu, 6 Jul 2000 14:55:07 -0400 Received: (qmail 8954 invoked from network); 6 Jul 2000 18:50:42 -0000 Received: from unknown (HELO secureworks.net) (63.239.86.253) by secureworks.net with SMTP; 6 Jul 2000 18:50:42 -0000 Sender: root@blueraja.scyld.com Message-ID: <3964D562.652DF0EC@secureworks.net> From: "John D. Scott" Organization: SecureWorks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: tulip@scyld.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [tulip] changing ethernet interface names Date: Thu Jul 6 14:55:08 2000 I work with a company called SecureWorks in Atlanta, GA. We are currently using phobos 4 port ethernet cards in our products. This card is based on the tulip 21142 chipset, and the latest version of the tulip driver works like a charm with the phobos cards (picking up all 4 interfaces); however, I have one question, and I hope it is not a stupid one. The proprietary drivers provided by phobos insisted upon the naming of the ethernet devices as pqfe0, pqfe1, pqfe2, and pqfe3. Of course, the tulip drivers name the interfaces as eth0, eth1, eth2, and eth3. The only problem is that we have written software that specifically uses the pqfe* device names. Is there an easy way to alter the tulip driver, allowing for a different interface naming scheme? I have been fooling around with the drivers, and having very little experience doing so, I am having trouble accomplishing the task of renaming the interfaces. Please let me know if there is a simple way to do this. I have to be missing something simple. Thanks very much in advance for any assistance you can offer. -John Scott From tulip-admin@blueraja.scyld.com Thu Jul 6 17:54:16 2000 Received: from vaio.greennet (georgia-2.dsl.speakeasy.net [216.254.93.178]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id RAA24112 for ; Thu, 6 Jul 2000 17:54:16 -0400 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id RAA15577; Thu, 6 Jul 2000 17:54:54 -0400 From: Donald Becker X-Sender: becker@vaio.greennet To: "John D. Scott" cc: tulip@scyld.com Subject: Re: [tulip] changing ethernet interface names In-Reply-To: <3964D562.652DF0EC@secureworks.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu Jul 6 17:54:17 2000 On Thu, 6 Jul 2000, John D. Scott wrote: > I work with a company called SecureWorks in Atlanta, GA. We are > currently using phobos 4 port ethernet cards in our products. This card > is based on the tulip 21142 chipset, and the latest version of the tulip > driver works like a charm with the phobos cards (picking up all 4 > interfaces); however, I have one question, and I hope it is not a stupid > one. > > The proprietary drivers provided by phobos insisted upon the naming of ??? I've not heard of this driver. Is it written from scratch, or based on the Tulip driver? > the ethernet devices as pqfe0, pqfe1, pqfe2, and pqfe3. Of course, the > tulip drivers name the interfaces as eth0, eth1, eth2, and eth3. The > only problem is that we have written software that specifically uses the > pqfe* device names. Is there an easy way to alter the tulip driver, > allowing for a different interface naming scheme? I have been fooling > around with the drivers, and having very little experience doing so, I > am having trouble accomplishing the task of renaming the interfaces. It's sleazy, but just hack the driver to put its own string in place of dev->name. You can add a new array in tulip_private char pqfe[16]; and then in tulip_probe1() do tp->next_module = root_tulip_dev; root_tulip_dev = dev; + sprintf(tp->pqfe, "pqfe%s", dev->name + 3); + dev->name = tp->pqfe; This is untested. We do driver validation if you wanted a tested version. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations Annapolis MD 21403 From tulip-admin@blueraja.scyld.com Fri Jul 7 04:21:40 2000 Received: from mail.wildbearnet.net (IDENT:root@[63.161.137.253]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id EAA28373 for ; Fri, 7 Jul 2000 04:19:09 -0400 Received: from panda (ip36.wildbearnet.net [63.161.137.36]) by mail.wildbearnet.net (8.9.3/8.9.3) with SMTP id BAA12885 for ; Fri, 7 Jul 2000 01:23:59 -0700 From: Joseph Parmelee X-Sender: jparmele@panda To: tulip@scyld.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tulip] Transmit timeout - perhaps a clue Date: Fri Jul 7 04:21:42 2000 We are using a Linksys LNE100TX which has been working well in a Pentium II/440BX production system since February. We discovered that we could induce almost immediately the ethernet transmit timeout error that has been widely reported when running either a 2.2.12 or 2.2.16 kernel by connecting /dev/ttyS0 to the RS232C back-port of our terminal server. The timeout errors appeared before any application using /dev/ttyS0 was even started. The terminal server sends data continuously, so I presume the RS232C receive interrupts (IRQ 4) are somehow inducing this. The NIC is on IRQ 10. Perhaps the fact that IRQ 4 is handled on the first level interrupt controller is important, but so are system clock (IRQ 0) and keyboard (IRQ 1), which don't cause the problem. Neither do any of the other interrupts on the cascaded interrupt controller; Cyclades T1 serial interace on IRQ 11, IDE controllers on IRQ 14 and IRQ 15. We did not try to induce the errors with the floppy disk controller (IRQ 6). No other IRQ on the first level controller above 2 is in use. Is there a silly interrupt handling bug involving the interrupt cascading lurking in the tulip driver? Sorry we don't have time to chase this right now, but will be happy to provide additional info. Our 2.2.12 kernel was built with tulip.c:v0.91g 7/16/99 downloaded from the Linksys website; our 2.2.16 kernel uses the stock tulip.c. Regards, Joe Parmelee Wild Bear Systems jparmele@wildbear.com From tulip-admin@blueraja.scyld.com Fri Jul 7 10:57:12 2000 Received: from praim.com (mail.praim.com [194.185.227.2]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id KAA31427 for ; Fri, 7 Jul 2000 10:57:10 -0400 Received: from [195.120.60.89] (rub089.tn00.ne.interbusiness.it) by praim.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 167-44480U100L100S0) with SMTP id AAA252 for ; Fri, 7 Jul 2000 16:49:23 +0200 From: andreae@praim.com (Andrea Endrizzi) X-Mailer: The Bat! (v1.44) UNREG / CD5BF9353B3B7091 Reply-To: "Andrea E." X-Priority: 3 (Normal) Message-ID: <163606070.20000707164948@praim.com> To: tulip@scyld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [tulip] unknows problem on mips Date: Fri Jul 7 10:57:13 2000 Hello Tulip-MailingList, I working on mips processor and i must use ST10/100 Chip Driver ( ADMTec ). On my i386 work pretty fine, but when i try to load the some driver on mips platform i receive the follow message when i try to ping another host. I have see that the packet dropped , when ping from i386 platform , incremet very fast. neighbour table overflow eth0: Transmit timed out, status fc685410, CSR12 00000000, resetting... NET: 2 messages suppressed. neighbour table overflow NET: 5 messages suppressed. neighbour table overflow NET: 2 messages suppressed. neighbour table overflow eth0: Transmit timed out, status fc685410, CSR12 00000000, resetting... NET: 5 messages suppressed. neighbour table overflow I think that the driver not have any bug , but i have wrong to programmer the PCI Controller. I hope that anyone help to understund the problem with the follow message. -- Best regards, Andrea mailto:andreae@praim.com From tulip-admin@blueraja.scyld.com Fri Jul 7 15:02:31 2000 Received: from vaio.greennet (georgia-2.dsl.speakeasy.net [216.254.93.178]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id PAA32519 for ; Fri, 7 Jul 2000 15:02:31 -0400 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id PAA20994; Fri, 7 Jul 2000 15:03:06 -0400 From: Donald Becker X-Sender: becker@vaio.greennet To: Andrea Endrizzi cc: tulip@scyld.com Subject: Re: [tulip] unknows problem on mips In-Reply-To: <163606070.20000707164948@praim.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri Jul 7 15:02:32 2000 On Fri, 7 Jul 2000, Andrea Endrizzi wrote: > I working on mips processor and i must use ST10/100 Chip Driver ( ADMTec ). On > my i386 work pretty fine, but when i try to load the some driver on mips > platform i receive the follow message when i try to ping another host. I have > see that the packet dropped , when ping from i386 platform , incremet very > fast. What driver are you using? What kernel version? > neighbour table overflow > eth0: Transmit timed out, status fc685410, CSR12 00000000, resetting... Try running 'tulip-diag' from http://www.scyld.com/diag/index.html Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations Annapolis MD 21403 From tulip-admin@blueraja.scyld.com Sat Jul 8 17:01:37 2000 Received: from devel.ecoaccess.org (user-152-16-66-119.adsl.duke.edu [152.16.66.119]) by blueraja.scyld.com (8.9.3/8.9.3) with SMTP id RAA05309 for ; Sat, 8 Jul 2000 17:01:36 -0400 Received: (qmail 6778 invoked from network); 8 Jul 2000 21:01:14 -0000 Received: from localhost (HELO ecoaccess.org) (127.0.0.1) by localhost with SMTP; 8 Jul 2000 21:01:14 -0000 Sender: fhorch@blueraja.scyld.com Message-ID: <3967969A.86D1AE97@ecoaccess.org> From: Fred Wilson Horch Organization: EcoAccess X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en-US,en-GB MIME-Version: 1.0 To: tulip@scyld.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [tulip] Failed to map PCI address ? Date: Sat Jul 8 17:01:37 2000 Does anyone know what 'Failed to map PCI address' means? We have a cluster of Linux 2.0.36 machines using (or rather, previously using) a 100 Mbps hub and four Kingston 100/10 Mbps NICs. Every three months or so the network would fail & we'd have to reboot to regain connectivity. By fail, what would happen is that most packets between nodes would be lost and packets that did get through would take five minutes or longer, essentially shutting down the entire cluster. We could never figure out what triggered this. The situation has gone from bad to worse in trying to fix it. One of the nodes has two NICs: an Intel EtherExpress Pro 10/100 that worked and still works fine (at 10 Mbps), and the Kingston NIC that was flaky. After updating to tulip.c:v0.92 4/17/2000, that machine has completely lost touch with the Kingston NIC. Here is the boot message: tulip.c:v0.92 4/17/2000 Written by Donald Becker http://www.scyld.com/network/tulip.html Failed to map PCI address 0xebfeef80. I tried swapping another Kingston NIC (same model) from another node in the cluster -- same message no matter which NIC is in the machine. Can anyone tell me what triggers this message ('Failed to map PCI address')? As far as I can tell, the hardware is okay. All the lights come on (on the card and on the hub). Linux sees the card. Here's the contents of /proc/ PCI devices found: [snip] Bus 0, device 6, function 0: Ethernet controller: Intel 82557 (rev 4). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=6 4. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0xffaff000. I/O at 0xef40. Non-prefetchable 32 bit memory at 0xebe00000. Bus 0, device 4, function 0: VGA compatible controller: S3 Inc. Trio64V2/DX or /GX (rev 22). Medium devsel. Non-prefetchable 32 bit memory at 0xec000000. Bus 0, device 3, function 0: Ethernet controller: DEC DC21140 (rev 34). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=64 . Min Gnt=20.Max Lat=40. I/O at 0xec80. Non-prefetchable 32 bit memory at 0xebfeef80. [snip] Here's what tulip-diag says: tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xec80. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. 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. modprobe by hand complains with /lib/modules/preferred/net/tulip.o: init_module: Device or resource busy I have another machine running Linux 2.2.12 with the same model Kingston NIC and tulip v0.92 that works fine. Before I try to upgrade the kernel on all our nodes (in sort of a Microsoft-esque attempt to solve a problem by loading on more software that we don't really need) or replace the NICs (in an Intel-esque attempt to solve a problem by buying new hardware), I'd like to make sure I understand what the 'Failed to map PCI address' message means. Any help would be appreciated. Thanks in advance, Fred -- Fred Wilson Horch mailto:fhorch@ecoaccess.org Executive Director, EcoAccess http://ecoaccess.org/ 2408 Prince St, Durham, NC 27707 phone: 919.419-8354 From tulip-admin@blueraja.scyld.com Sat Jul 8 18:34:33 2000 Received: from mail.arcor-ip.de (mail-ffm-p.arcor-ip.de [145.253.2.10]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id SAA05663 for ; Sat, 8 Jul 2000 18:34:33 -0400 Received: from nepomuk (212.144.204.1) by mail.arcor-ip.de; 9 Jul 2000 00:29:52 +0200 Received: by nepomuk (Postfix, from userid 1000) id 05D3AAE4C; Sun, 9 Jul 2000 00:20:48 +0200 (CEST) From: Philipp Schulte To: tulip@scyld.com Subject: Re: [tulip] Failed to map PCI address ? Message-ID: <20000709002048.A12221@nepomuk> Mail-Followup-To: tulip@scyld.com References: <3967969A.86D1AE97@ecoaccess.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3967969A.86D1AE97@ecoaccess.org>; from fhorch@ecoaccess.org on Sat, Jul 08, 2000 at 05:01:14PM -0400 X-Mailer: Mutt 1.2 Sender: phil@nepomuk.nepomuk Date: Sat Jul 8 18:34:34 2000 On Sat, Jul 08, 2000 at 05:01:14PM -0400, Fred Wilson Horch wrote: > Does anyone know what 'Failed to map PCI address' means? I don't know what it means but I know how to avoid it :) I had this problemsome time ago and Mr. Becker told me to do this: Compile tulip.c v92 with the *additional* flag '-DUSE_IO_OPS' I could compile the module with this option and never saw this message again. Phil From tulip-admin@blueraja.scyld.com Sat Jul 8 21:01:36 2000 Received: from devel.ecoaccess.org (user-152-16-66-119.adsl.duke.edu [152.16.66.119]) by blueraja.scyld.com (8.9.3/8.9.3) with SMTP id VAA06181 for ; Sat, 8 Jul 2000 21:01:36 -0400 Received: (qmail 6846 invoked from network); 9 Jul 2000 01:01:13 -0000 Received: from localhost (HELO ecoaccess.org) (127.0.0.1) by localhost with SMTP; 9 Jul 2000 01:01:13 -0000 Sender: fhorch@blueraja.scyld.com Message-ID: <3967CED9.779F58BB@ecoaccess.org> From: Fred Wilson Horch Organization: EcoAccess X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en-US,en-GB MIME-Version: 1.0 To: tulip@scyld.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [tulip] Re: Failed to map PCI address ? (Problem solved!) Date: Sat Jul 8 21:01:37 2000 On Sat, Jul 08, 2000, Philipp Schulte wrote: >> Does anyone know what 'Failed to map PCI address' means? > >I don't know what it means but I know how to avoid it :) >I had this problemsome time ago and Mr. Becker told me to do this: >Compile tulip.c v92 with the *additional* flag '-DUSE_IO_OPS' Wow, that's impressive -- worked like a charm! I recompiled tulip.c with this command: gcc -DMODULE -DUSE_IO_OPS -Wall -Wstrict-prototypes -O6 -c tulip.c Then I was able to modprobe tulip, and bring up the interface. We are in business! Thanks! Now, what did I just do? ;-) /proc/ioports shows [snip] ec80-ecff : eth1 ef40-ef5f : Intel Speedo3 Ethernet /proc/interrupts shows [snip] 9: 25 eth1 10: 223900 Intel EtherExpress Pro 10/100 Ethernet [snip] I see the comment in the source of tulip.c: /* This driver was originally written to use I/O space access, but now uses memory space by default. Override this this with -DUSE_IO_OPS. */ Is there any practical difference between the two (I/O space access vs. memory space access), aside from the obvious (i.e., that memory space doesn't work for me)? Why was the driver rewritten to use memory space by default? -- Fred Wilson Horch mailto:fhorch@ecoaccess.org Executive Director, EcoAccess http://ecoaccess.org/ 2408 Prince St, Durham, NC 27707 phone: 919.419-8354 From tulip-admin@blueraja.scyld.com Sat Jul 8 23:26:00 2000 Received: from vaio.greennet (adsl-151-196-242-87.bellatlantic.net [151.196.242.87]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id XAA06683 for ; Sat, 8 Jul 2000 23:25:59 -0400 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id XAA26934; Sat, 8 Jul 2000 23:26:59 -0400 From: Donald Becker X-Sender: becker@vaio.greennet To: Fred Wilson Horch cc: tulip@scyld.com Subject: Re: [tulip] Re: Failed to map PCI address ? (Problem solved!) In-Reply-To: <3967CED9.779F58BB@ecoaccess.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sat Jul 8 23:26:00 2000 On Sat, 8 Jul 2000, Fred Wilson Horch wrote: > On Sat, Jul 08, 2000, Philipp Schulte wrote: > >> Does anyone know what 'Failed to map PCI address' means? > > > >I don't know what it means but I know how to avoid it :) > >I had this problemsome time ago and Mr. Becker told me to do this: > >Compile tulip.c v92 with the *additional* flag '-DUSE_IO_OPS' > > Wow, that's impressive -- worked like a charm! > > I recompiled tulip.c with this command: > > gcc -DMODULE -DUSE_IO_OPS -Wall -Wstrict-prototypes -O6 -c tulip.c ... > Now, what did I just do? ;-) The Tulip registers may be accessed using either I/O space operations, or using memory space operations. This compile option switches to using I/O space operations, which was the original mode the driver used. The BIOS sets both the I/O base address and the memory base address. On the PC architecture I/O space access is traditionally used for peripherals, and is sometime the only method tested. The problem you are experiencing is that the Tulip's memory space is set to a high address, and the 2.0.* kernel is apparently unable to map that address. Thus the driver+kernel works with most BIOSes, but fails with yours. The 2.2.* kernel uses a different kernel memory mapping, and thus works with all BIOSes. I'll change the Tulip driver (and others) to alway use the I/O space mapping with the pre-2.2 kernels. > I see the comment in the source of tulip.c: > > /* This driver was originally written to use I/O space access, but now > uses memory space by default. Override this this with -DUSE_IO_OPS. > */ > > Is there any practical difference between the two (I/O space access vs. > memory space access), aside from the obvious (i.e., that memory space > doesn't work for me)? Why was the driver rewritten to use memory space > by default? Memory space write operations can be more efficient on most recent systems. If you do a single memory write operation it's put into the cache-coherent write buffer, and the CPU continues operation without delay. The similar I/O 'outl' operation will cause the CPU to wait until the PCI bus transaction completes. This efficiency is most obvious when transmitting a packet. The only PCI transaction necessary is a writel or outl that triggers the chip to check the Tx queue. (The chip can poll on Tx descriptors, but that adds latency.) Don't get the mis-impression that waiting one additional PCI transaction per Tx and packet and interrupt cycle is significant. It isn't going to be measurable, let alone noticeable. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations Annapolis MD 21403 From tulip-admin@blueraja.scyld.com Mon Jul 10 03:58:35 2000 Received: from jeeves.blindglobe.net (sense-sea-MegaSub-1-346.oz.net [216.39.145.92]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id DAA11037 for ; Mon, 10 Jul 2000 03:58:34 -0400 Received: from rossini (helo=localhost) by jeeves.blindglobe.net with local-esmtp (Exim 3.12 #1 (Debian)) id 13BYO1-0006Vx-00 for ; Mon, 10 Jul 2000 00:53:53 -0700 From: "A.J. Rossini" To: tulip@scyld.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tulip] Netgear FA310-TX NIC problems Date: Mon Jul 10 03:58:36 2000 I'm seeing similar problems as previously reported, with the FA310TX locking up after heavy traffic (say, strobe, portscan, solid X, NFS), not during "normal user" use (telnet, scp, ftp for remote (non-LAN) sites. Has anyone found a solution? I'm about to go back to 3Com/Intel NICs, since this is the first time in years (with Linux, can you say, 7!) that I've actually had a serious network problem that I couldn't solve (networking locks up cold -- ifconfig reports existence, but I can't ping/telnet/whatever out, I can't look in, and tulip-diag reports similar to previous reports (can't see now, I'm connected :-), but basically Tx no Rx (or vice-versa)). From a major perusal of the archives from this list, from the Debian lists, and from Google/Altavista, it looks like lots of people have success with this NIC, provided that they are running it at 100Base-T or from switched ether (i.e. full-duplex). A simple metaanalysis seems to suggest that the lockups occur at autodection, running 10BaseT through a hub, or half-duplex, and that resetting the network cures it (I have found this to be true, but it's silly to run an every 2-minute cron job to ensure access). Thoughts? I've been running the drivers from the 2.2.17pre kernel (Debian potato/woody), which is the 0.91g-ppc version. I've just upped the debug level, and will take it through it's paces a few more times. Also, someone has suggested upping a collision parameter before for the options, or setting the interface explicitly to 10BaseT. Can anyone report this being useful? best, -tony --- A.J. Rossini rossini@blindglobe.net BlindGlobe Networks (personal use) rossini@biostat.washington.edu UW Biostat/Center for AIDS Research From tulip-admin@blueraja.scyld.com Mon Jul 10 04:19:11 2000 Received: from vaio.greennet (adsl-151-196-242-26.bellatlantic.net [151.196.242.26]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id EAA11166 for ; Mon, 10 Jul 2000 04:19:10 -0400 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id EAA01730; Mon, 10 Jul 2000 04:20:21 -0400 From: Donald Becker X-Sender: becker@vaio.greennet To: "A.J. Rossini" cc: tulip@scyld.com Subject: Re: [tulip] Netgear FA310-TX NIC problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon Jul 10 04:19:13 2000 On Mon, 10 Jul 2000, A.J. Rossini wrote: > I'm seeing similar problems as previously reported, with the FA310TX Which version of the FA310TX? What is the detection message? > Thoughts? I've been running the drivers from the 2.2.17pre kernel > (Debian potato/woody), which is the 0.91g-ppc version. You should try v92. 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 Beowulf Clusters / Linux Installations Annapolis MD 21403 From tulip-admin@blueraja.scyld.com Mon Jul 10 10:12:00 2000 Received: from jeeves.blindglobe.net (sense-sea-MegaSub-1-346.oz.net [216.39.145.92]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id KAA12671; Mon, 10 Jul 2000 10:11:59 -0400 Received: from rossini (helo=localhost) by jeeves.blindglobe.net with local-esmtp (Exim 3.12 #1 (Debian)) id 13BeDL-0000Dz-00; Mon, 10 Jul 2000 07:07:15 -0700 From: "A.J. Rossini" To: Donald Becker cc: tulip@scyld.com Subject: Re: [tulip] Netgear FA310-TX NIC problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon Jul 10 10:12:01 2000 On Mon, 10 Jul 2000, Donald Becker wrote: > On Mon, 10 Jul 2000, A.J. Rossini wrote: > > > I'm seeing similar problems as previously reported, with the FA310TX > > Which version of the FA310TX? Here's what I can tell: # ./tulip-diag -m -m tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xde00. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 3000 782d 0040 6212 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 5000 0000 0000 0000 0000 0000 0300 0000 003c 8006 0f00 ff00 002c 4000 0080 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. No specific information is known about this transceiver type. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. > What is the detection message? From dmesg/kernel boot: tulip.c:v0.92 4/17/2000 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: Lite-On 82c168 PNIC rev 32 at 0xcc843f00, 00:A0:CC:65:E6:AE, IRQ 10. eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. > > Thoughts? I've been running the drivers from the 2.2.17pre kernel > > (Debian potato/woody), which is the 0.91g-ppc version. > > You should try v92. > http://www.scyld.com/network/tulip.html > ftp://www.scyld.com/pub/network/tulip.c > Tried and failed with the same problem. Using tulip debug=1, I've been getting the lock-up regularly using "strobe" against a local machine. This knocks out networking to all machines, and I start getting the following error: eth0: Transmit timeout using MII device. At this point, the above diagnostics look like: http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xde00. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 3000 782d 0040 6212 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 5000 0000 0000 0000 0000 0000 0400 0000 003c 8006 0f00 ff00 002c 4000 0080 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. No specific information is known about this transceiver type. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. (note that the top portion of tulip-diag scrolled off my screen too fast, but it basically said the same thing as before, wrt tulip diag.) Any more thoughts/approaches to try? best, -tony ---- A.J. Rossini rossini@blindglobe.net BlindGlobe Networks rossini@biostat.washington.edu UW Biostat/Center for AIDS Research From tulip-admin@blueraja.scyld.com Mon Jul 10 10:36:58 2000 Received: from jeeves.blindglobe.net (sense-sea-MegaSub-1-346.oz.net [216.39.145.92]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id KAA12829 for ; Mon, 10 Jul 2000 10:36:58 -0400 Received: from rossini (helo=localhost) by jeeves.blindglobe.net with local-esmtp (Exim 3.12 #1 (Debian)) id 13BebW-0000Gc-00 for ; Mon, 10 Jul 2000 07:32:14 -0700 From: "A.J. Rossini" To: tulip@scyld.com Subject: Re: [tulip] Netgear FA310-TX NIC problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon Jul 10 10:36:59 2000 I should mention that a kind soul provided a temporary solution, in terms of scripts that babysit the NIC and reset it when lockup occurs. But this is a truly ugly (hopefully temporary) hack. best, -tony --- A.J. Rossini rossini@blindglobe.net BlindGlobe Networks rossini@biostat.washington.edu UW Biostat/CFAR From tulip-admin@blueraja.scyld.com Mon Jul 10 10:57:48 2000 Received: from vaio.greennet (adsl-151-196-244-106.bellatlantic.net [151.196.244.106]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id KAA13016 for ; Mon, 10 Jul 2000 10:57:47 -0400 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id KAA02391; Mon, 10 Jul 2000 10:59:00 -0400 From: Donald Becker X-Sender: becker@vaio.greennet To: "A.J. Rossini" cc: tulip@scyld.com Subject: Re: [tulip] Netgear FA310-TX NIC problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon Jul 10 10:57:49 2000 On Mon, 10 Jul 2000, A.J. Rossini wrote: > On Mon, 10 Jul 2000, Donald Becker wrote: > > On Mon, 10 Jul 2000, A.J. Rossini wrote: > > > > > I'm seeing similar problems as previously reported, with the FA310TX > > Which version of the FA310TX? I'm asking because the "FA310TX" name refers to three or four different chips and transceiver configurations. > Here's what I can tell: > # ./tulip-diag -m -m > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xde00. > Port selection is MII, half-duplex. This is either the second or third generation PNIC-I design. It's probably the third generation, a '169 with an external MII transceiver. > Transmit started, Receive started, half-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 72. This is normal. > MII PHY found at address 1, status 0x782d. > MII PHY #1 transceiver registers: > 3000 782d 0040 6212 01e1 0021 0000 0000 > Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. > No specific information is known about this transceiver type. If it's easy to look at the board itself, what is the brand and part number of the transceiver? (Probably unimportant, but I'll see if I can add it to libmii.c). > > What is the detection message? > tulip.c:v0.92 4/17/2000 Written by Donald Becker > http://www.scyld.com/network/tulip.html > eth0: Lite-On 82c168 PNIC rev 32 at 0xcc843f00, 00:A0:CC:65:E6:AE, IRQ 10. > eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. Ahhh, rev. 32, definitely a '169 with the fixed MII register hardware. > > You should try v92. > Tried and failed with the same problem. > eth0: Transmit timeout using MII device. > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xde00. > Port selection is MII, half-duplex. > Transmit started, Receive started, half-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Waiting for Tx to finish'. > The transmit threshold is 72. OK, the transmitter is waiting to be able to transmit. Either the chip thinks the media is busy, or something has gone wrong. The PCI transfer unit is likely OK, and interrupts are getting through. (The latter is an important point -- our BP6 cluster nodes pretty consistently forget how to handle interrupts after a few days unless we turn off the flaky APIC code with "noapic".) > MII PHY #1 transceiver registers: > 3000 782d 0040 6212 01e1 0021 0000 0000 Hmmm, looks normal. > (note that the top portion of tulip-diag scrolled off my screen too fast, > but it basically said the same thing as before, wrt tulip diag.) I'll need the output from 'tulip-diag -af'. It's easiest to do tulip-diag -af > /tmp/t-d-working then tulip-diag -af > /tmp/t-d-broken Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations Annapolis MD 21403 From tulip-admin@blueraja.scyld.com Mon Jul 10 11:05:40 2000 Received: from jeeves.blindglobe.net (sense-sea-MegaSub-1-346.oz.net [216.39.145.92]) by blueraja.scyld.com (8.9.3/8.9.3) with ESMTP id LAA13195; Mon, 10 Jul 2000 11:05:38 -0400 Received: from rossini (helo=localhost) by jeeves.blindglobe.net with local-esmtp (Exim 3.12 #1 (Debian)) id 13Bf3F-0000K9-00; Mon, 10 Jul 2000 08:00:53 -0700 From: "A.J. Rossini" To: Donald Becker cc: tulip@scyld.com Subject: Re: [tulip] Netgear FA310-TX NIC problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon Jul 10 11:05:40 2000 On Mon, 10 Jul 2000, Donald Becker wrote: > I'm asking because the "FA310TX" name refers to three or four different > chips and transceiver configurations. I'll open it up tonight when I get back from work. > If it's easy to look at the board itself, what is the brand and part number > of the transceiver? (Probably unimportant, but I'll see if I can add it to > libmii.c). Again, will do tonight. Does this mean you don't need it, or still do? > Ahhh, rev. 32, definitely a '169 with the fixed MII register hardware. > I'll need the output from 'tulip-diag -af'. It's easiest to do > tulip-diag -af > /tmp/t-d-working Here it is: tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapt