From Claus.Rosenberger@rocnet.de Sat Jun 1 15:20:04 2002 From: Claus.Rosenberger@rocnet.de (Claus Rosenberger) Date: Sat Jun 1 14:20:04 2002 Subject: [eepro100] eepro100 and e1000 Message-ID: <35498.192.168.100.100.1022522877.squirrel@deathstar.rocnet.de> hi, i want to use the eepro100 and the e1000 in the same machine. until now i compiled modules and had some alias eth0 and eth1 for this cards. but now i want to build the drivers staticly to the kernel. how i can force to load the eepro100 as device eth0 and the e1000 as device eth1 ? the kernel load the devices all the time in wrong order. thanks claus From Claus.Rosenberger@rocnet.de Sat Jun 1 15:21:58 2002 From: Claus.Rosenberger@rocnet.de (Claus Rosenberger) Date: Sat Jun 1 14:21:58 2002 Subject: [eepro100] eepro100 and e1000 staticly linked Message-ID: <4055.192.168.100.10.1022609663.squirrel@deathstar.rocnet.de> Hi, i have a big problem and searched since a lot of days now for a solution. Does anybody know how to load staticly linked ethernet drivers in specific orderwhile booting linux. I tried append="ether=10,0xe000,eth0 ether=10,0xd800,eth1", but now success. I have two pci cards same type and want to load the card with address 0xd800 at first time with interface name eth0. I have the same problem if i have different cards like eepro100 and e1000. The problem is that i cannot link e1000 dynamicly because it's not supported at this time. Please help Claus From trevj@redbrick.dcu.ie Sun Jun 2 14:48:00 2002 From: trevj@redbrick.dcu.ie (Trevor Johnston) Date: Sun Jun 2 13:48:00 2002 Subject: [eepro100] Flashing Onboard 82562EM Message-ID: Hello all, I have what will hopefully be an easily answered question. I have a Gigabyte FA1UB with an Intel 810E2 motherboard with an eepro100 compatible (82562 to be exact) onboard NIC. We are considering using 30 of these machines as thin client in a classroom. Opting to Boot from LAN (in the BIOS) produces no effect; following instructions from the distribution of etherboot I tried to use PBOOT.EXE to place an etherboot ROM onto the card's flash memory. But PBOOT won't recognise the onboard card! So, I wish to use Donald Becker's eepro100-diag program to flash it instead. I compiled it with both libmii and libflash. It recognises the card and -e and -ee options work, but neither -B nor -S work. However, mailing list messages seem to indicate that eepro100-diag can flash the ROM. But I would rather not without a backup of the current contents. To finish, does the -e option really read the flash? Could eepro100-diag be easily hacked to dump its current contents to a file, rather than using the -S option (which doesn't work)? Will eepro100-diag perform a similar function to PBOOT.EXE? Any help is much appreciated. Trevor Johnston From subscriptions@graphon.com Tue Jun 4 18:21:01 2002 From: subscriptions@graphon.com (Nate Amsden) Date: Tue Jun 4 17:21:01 2002 Subject: [eepro100] eepro100 and e1000 References: <35498.192.168.100.100.1022522877.squirrel@deathstar.rocnet.de> Message-ID: <3CFD2ED3.A0430D7@graphon.com> Claus Rosenberger wrote: > > hi, > > i want to use the eepro100 and the e1000 in the same machine. until now i > compiled modules and had some alias eth0 and eth1 for this cards. but now > i want to build the drivers staticly to the kernel. how i can force to > load the eepro100 as device eth0 and the e1000 as device eth1 ? > the kernel load the devices all the time in wrong order. change the order of the PCI cards, the kernel should assign them in the order that they are detected, so if they are PCI cards, flip em around, and it should get reversed. if one is onboard ..well I am not sure what you can do. nate -- Nate Amsden System Administrator GraphOn http://www.graphon.com From wizard@securesoft.com Tue Jun 4 23:51:01 2002 From: wizard@securesoft.com (=?euc-kr?B?vK289r/4?=) Date: Tue Jun 4 22:51:01 2002 Subject: [eepro100] [Question]1.6.29 module to kernel source tree Message-ID: I want to latest linux device module for eepro100 into built-in kernel my kernel version is 2.4.9 and eepro100 device driver kernel module is 1.6.29 how could I try this? in reference supported by intel , there are stuffs only for modules.. From becker@scyld.com Wed Jun 5 00:19:02 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jun 4 23:19:02 2002 Subject: [eepro100] Flashing Onboard 82562EM In-Reply-To: Message-ID: On Sun, 2 Jun 2002, Trevor Johnston wrote: > I have a Gigabyte FA1UB with an Intel 810E2 motherboard with an eepro100 > compatible (82562 to be exact) onboard NIC. We are considering using 30 of > these machines as thin client in a classroom. ... > So, I wish to use Donald Becker's eepro100-diag program to flash it > instead. I compiled it with both libmii and libflash. It recognises the > card and -e and -ee options work, but neither -B nor -S work. However, > mailing list messages seem to indicate that eepro100-diag can flash the > ROM. But I would rather not without a backup of the current contents. Writing the flash requires kernel support for mapping the boot ROM. This kernel support does not exist in standard kernels, thus the eepro100-diag can not read or write the flash. -- 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 christoph.plattner@alcatel.at Wed Jun 5 04:53:00 2002 From: christoph.plattner@alcatel.at (Christoph Plattner) Date: Wed Jun 5 03:53:00 2002 Subject: [eepro100] eepro100 and e1000 References: <35498.192.168.100.100.1022522877.squirrel@deathstar.rocnet.de> <3CFD2ED3.A0430D7@graphon.com> Message-ID: <3CFDC31F.EE30FAA4@alcatel.at> Try to patch the driver only searching for "one" VENDOR_ID/CHIP_ID on the PCI bus. Christoph P. Nate Amsden wrote: > > Claus Rosenberger wrote: > > > > hi, > > > > i want to use the eepro100 and the e1000 in the same machine. until now i > > compiled modules and had some alias eth0 and eth1 for this cards. but now > > i want to build the drivers staticly to the kernel. how i can force to > > load the eepro100 as device eth0 and the e1000 as device eth1 ? > > the kernel load the devices all the time in wrong order. > > change the order of the PCI cards, the kernel should assign them in the order > that they are detected, so if they are PCI cards, flip em around, and > it should get reversed. if one is onboard ..well I am not sure what > you can do. > > nate > > -- > Nate Amsden > System Administrator > GraphOn > http://www.graphon.com > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 -- +--------V--------+ Christoph.Plattner@alcatel.at | A L C A T E L | ----------------------------- +-----------------+ Phone: +43 1 27722 3706 T A S Fax: +43 1 27722 3955 From jan.johansson@viking-telecom.com Wed Jun 5 09:00:01 2002 From: jan.johansson@viking-telecom.com (Jan Johansson) Date: Wed Jun 5 08:00:01 2002 Subject: [eepro100] EE Pro 10/100 network drop outs using e100. Message-ID: >Perhaps this wouldn't be so bad except that even after 4:26pm yesterday no >traffic would go over the link, even though the above message suggests that >it is up. Bringing the interface down, removing the e100 module and >insmod'ing it again didn't work. It was necessary to reboot the server to >correct this. I have the exact same phenomenon on a Debian 3.0 / 2.4.18 system, ruinning on a ABIT BP6 with 2 x Celeron 433. Any advice? From becker@scyld.com Wed Jun 5 13:39:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 5 12:39:01 2002 Subject: [eepro100] eepro100 and e1000 In-Reply-To: <3CFDC31F.EE30FAA4@alcatel.at> Message-ID: On Wed, 5 Jun 2002, Christoph Plattner wrote: > Nate Amsden wrote: > > Claus Rosenberger wrote: > > > > > > i want to use the eepro100 and the e1000 in the same machine. until now i > > > compiled modules and had some alias eth0 and eth1 for this cards. but now > > > i want to build the drivers staticly to the kernel. how i can force to > > > load the eepro100 as device eth0 and the e1000 as device eth1 ? > > > the kernel load the devices all the time in wrong order. In this case the detection order is set by the order that the driver probes are called. Since the e1000 driver is only distributed as a module, you must have added the e1000 probe into the code yourself. Just change the order. > > change the order of the PCI cards, the kernel should assign them in the order > > that they are detected, so if they are PCI cards, flip em around, and > > it should get reversed. if one is onboard ..well I am not sure what > > you can do. That's only true for multiple cards supported by a single driver. The driver probe detects all supported cards. > Try to patch the driver only searching for "one" VENDOR_ID/CHIP_ID > on the PCI bus. That won't do it. And changing the driver to "skip" unrecognized network cards isn't an option -- how can a one driver know that some other network driver will be supporting that device and filling in the naming "hole"? -- 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 Jun 5 16:36:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 5 15:36:00 2002 Subject: [eepro100] New eepro100.c v1.23 6/5/2002 Message-ID: Here is the check-in entry eepro100.c:v1.23 6/5/2002 Corrected bogus 'idebug' module parameter name change put in 1.20. Added a table entry for the "Pro/100 VM type 1038" 0x8086 0x1038. Changed do_slow_command() to emit more information when a command fails. Do a PortPartialReset if the command unit is busy when we start the interface. Always read-after-write when loading the SCBPointer register. Changed comment text at the beginning of the file. Added MODULE_PARM_DESC() entries for comment parameters. -- 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 trevj@redbrick.dcu.ie Wed Jun 5 20:00:01 2002 From: trevj@redbrick.dcu.ie (Trevor Johnston) Date: Wed Jun 5 19:00:01 2002 Subject: [eepro100] Flashing Onboard 82562EM In-Reply-To: Message-ID: On Tue, 4 Jun 2002, Donald Becker wrote: > > So, I wish to use Donald Becker's eepro100-diag program to flash it > > instead. I compiled it with both libmii and libflash. It recognises the > > card and -e and -ee options work, but neither -B nor -S work. However, > > mailing list messages seem to indicate that eepro100-diag can flash the > > ROM. But I would rather not without a backup of the current contents. > > Writing the flash requires kernel support for mapping the boot > ROM. This kernel support does not exist in standard kernels, thus the > eepro100-diag can not read or write the flash. Thanks for clearing that up, Donald. Might I respectfully suggest that it might be a good idea sometime in the future if the utilities were a little clearer on exactly which options were supported? Regardless, your utilities (and drivers) are excellent. Trevor Johnston From bayolabule23us@yahoo.com Wed Jun 5 22:23:01 2002 From: bayolabule23us@yahoo.com (Dr BAYOLA BULE) Date: Wed Jun 5 21:23:01 2002 Subject: [eepro100] REQUEST FOR YOUR UNRESERVED Message-ID: <200206060122.g561MoO28132@blueraja.scyld.com> FROM: DR. BAYOLA BULE BANK MANAGER (UNION BANK OF NIGERIA PLC)MARINA LAGOS ATTENTION: PRESIDENT/CEO Dear Sir, REQUEST FOR YOUR UNRESERVED ASSISTANCE Firstly, I must solicit your confidence in this transaction, this is by virtue of its nature as being utterly confidential and top secret. Though I know that a transaction of this magnitude will make any one apprehensive and worried, but I am assuring you that all will be well at the end of the day. We have decided to contact you due to the urgency of this transaction, as we have been reliably informed of it's swiftness and confidentiality. Let me start by first introducing myself properly to you. I am DR. BAYOLA BULE, a Manager at the Union Bank Nigeria PLC, Lagos. I came to know of you in my private search for a reliable and reputable person to handle a very confidential transaction, which involves the transfer of a huge sum of money to a foreign account requiring maximum confidence. A foreigner, Late Engineer William Adams, an oil Merchant /contractor with the federal Government of Nigeria, until his death three years ago in a ghastly air crash, banked with us here at the Union Bank PLC ,Lagos, and had a closing balance of USD$22.2M (Twenty-Two Million, Two Hundred Thousand United States Dollars) which the bank now unquestionably expects to be claimed by any of his available foreign next of kin or alternatively be donated to a discredited trust fund for arms and ammunition at a military war collage here in Nigeria. Fervent valuable efforts are being made by the Union Bank to get in touch with any of late Engr. William Adams's next of kin (he had no known wife and children) that the management under the influence of our chairman, board of directors, Retired Major General Kalu Uke Kalu, that an arrangement for the fund to be declared "UNCLIAMABLE " and then be subsequently donated to the trust fund for Arms and Ammunition, which will further enhance the course of war in Africa and the world in general. In order to avert this negative development, myself and some of my trusted colleagues in the bank now seek for your permission to have you stand as late Engr.WILLIAMS ADAMSs next of kin so that the fund, USD$22.2M, would be subsequently transferred and paid into your bank account as the beneficiary next of kin. All documents and proves to enable you get this fund have been carefully worked out and we are assuring you a 100% risk free involvement. Your share would be 30% of the total amount. 10% has been set aside for expenses, while the rest would be for myself and my colleagues for purposes in your country. If this proposal is OK by you and you do not wish to take advantage of the trust we hope to bestow on you and your company, then kindly get to me immediately via my e-mail address furnishing me with your most confidential telephone, fax and e-mail, so that I can forward to you the relevant details of this transaction. Thank you in advance for your anticipated co-operation. Regards. DR. BAYOLA BULE (MANAGER UNION BANK OF NIGERIA PLC). From christoph.plattner@alcatel.at Thu Jun 6 03:02:03 2002 From: christoph.plattner@alcatel.at (Christoph Plattner) Date: Thu Jun 6 02:02:03 2002 Subject: [eepro100] eepro100 and e1000 References: Message-ID: <3CFEFACF.518AB18@alcatel.at> Hello, I never thought this for a release driver ! I only wanted to give a hint for the problem of Nate Amsden to do a "quick&dirty" solution for his constellation. He knows which cards exactly he has, and which ID they have. Never think, I would do such a thing in a driver in general !! I know the probling methods, and I know your drivers very well. BTW: I never had an e1000 card in my hands..... Christoph Donald Becker wrote: > > On Wed, 5 Jun 2002, Christoph Plattner wrote: > > Nate Amsden wrote: > > > Claus Rosenberger wrote: > > > > > > > > i want to use the eepro100 and the e1000 in the same machine. until now i > > > > compiled modules and had some alias eth0 and eth1 for this cards. but now > > > > i want to build the drivers staticly to the kernel. how i can force to > > > > load the eepro100 as device eth0 and the e1000 as device eth1 ? > > > > the kernel load the devices all the time in wrong order. > > In this case the detection order is set by the order that the driver > probes are called. > Since the e1000 driver is only distributed as a module, you must have > added the e1000 probe into the code yourself. Just change the order. > > > > change the order of the PCI cards, the kernel should assign them in the order > > > that they are detected, so if they are PCI cards, flip em around, and > > > it should get reversed. if one is onboard ..well I am not sure what > > > you can do. > > That's only true for multiple cards supported by a single driver. The > driver probe detects all supported cards. > > > Try to patch the driver only searching for "one" VENDOR_ID/CHIP_ID > > on the PCI bus. > > That won't do it. And changing the driver to "skip" unrecognized > network cards isn't an option -- how can a one driver know that some > other network driver will be supporting that device and filling in the > naming "hole"? > > -- > 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 -- +--------V--------+ Christoph.Plattner@alcatel.at | A L C A T E L | ----------------------------- +-----------------+ Phone: +43 1 27722 3706 T A S Fax: +43 1 27722 3955 From steve@extex.com Thu Jun 6 12:51:01 2002 From: steve@extex.com (Steve Keith) Date: Thu Jun 6 11:51:01 2002 Subject: [eepro100] ifconfig In-Reply-To: <200206060122.g561MoO28132@blueraja.scyld.com> Message-ID: <5.1.0.14.0.20020606084649.00a02d80@linuxbox2> I'm running a Tyan Tiger 200T motherboard with dual Intel 82559 controllers. I am currently using only one of them. I periodically (a few times a day) check the status of the eth0 interface with ifconfig. Do the values reported by ifconfig for RX and TX bytes ever reset themselves? Yesterday the TX bytes were several gigabytes, but today it is under 600 megabytes. RX appears to be a little higher than yesterday as would be expected. The man pages were no help. Sorry if this is an inappropriate question for this forum. Thanks, Steve From robertf@appliedepi.com Fri Jun 7 11:25:01 2002 From: robertf@appliedepi.com (Robert Fentiman) Date: Fri Jun 7 10:25:01 2002 Subject: [eepro100] eth0: card reports no resources - can you help me identify which version of this problem I'm having? Message-ID: <66974D92E0A57741A23D3876BF6806410EF7DB@mail.appliedepi.com> After looking through the ML archives, I know you're probably tired of hearing this one, but even so I would appreciate your help in tracking down which version of the cause and possible solution for the problem I'm seeing. I'm seemingly randomly getting the following message printed out on the screen: eth0: card reports no resources I'm getting no other messages. I don't seem to be loosing my network connection at all. The message occurs even when the device is not doing anything active on the network (e.g. no specific connections, just sitting idle), although it is hooked up to our network. The hardware we're using is a WinSystems 5x86 133mhz PC104 motherboard with an on-board 82559ER. It has 64 megs of memory, and we haven't been running into any low memory situations that I can find. The OS is a Red Hat 7.0 distribution running the 2.2.16-22 Kernel. The driver is called eepro100, though I'm not sure what version as I'm just using the default distributed with that OS. I've read about various causes/solutions to this issue, however they all seemed to have other symptoms I'm not seeing (e.g. network connection loss, additional error messages, etc). Any help would be gratefully accepted. Thanks! -- Robert Fentiman Software Quality Engineer Veeco-Applied EPI robertf@appliedepi.com From becker@scyld.com Fri Jun 7 16:51:00 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jun 7 15:51:00 2002 Subject: [eepro100] ifconfig In-Reply-To: <5.1.0.14.0.20020606084649.00a02d80@linuxbox2> Message-ID: On Thu, 6 Jun 2002, Steve Keith wrote: > I'm running a Tyan Tiger 200T motherboard with dual Intel 82559 > controllers. I am currently using only one of them. I periodically > (a few times a day) check the status of the eth0 interface with > ifconfig. You should use 'cat /proc/net/dev' to see all of the raw numbers. The 'ifconfig' program summarizes or ignores some of the error counts. > Do the values reported by ifconfig for RX and TX bytes ever reset themselves? The values are never reset. They start at zero when the driver is initialized, and wrap around at 2^32 (on 32 bit machines). The is the correct and desired behavior. Many programs, expecially SNMP reporting, expect monotonically increasing, wrapping values. -- 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 wyb@ccert.com.cn Sun Jun 9 23:09:00 2002 From: wyb@ccert.com.cn (wyb) Date: Sun Jun 9 22:09:00 2002 Subject: [eepro100] full duplex problem Message-ID: <001701c21023$97ef7e30$a808a8c0@CODINGMAN> I made a linux firewall and tested it with SMARTBITS, got following result: (UDP test) 1. Set SMARTBIT working at auto negotiation 100M full duplex, got 14MBPS throughput under 1024bytes frame size. 2. Set SMARTBIT working at forced 100M full duplex, got 100MBPS throughput under 1024bytes frame size. 3. set SMARTBIT working at forced 100M full duplex 64 frame size, found that packets could only went from eth1 to eth0, RX of eth1 and TX of eth0 kept increasing, TX of eth1 and RX of eth0 didn't change. Then I changed frame size to 1024bytes, same problem occured again. Linux kernel 2.2.13, two Intel 82559 NIC, drivers version: v1.19 12/19/2001 From subscriptions@graphon.com Tue Jun 11 15:07:01 2002 From: subscriptions@graphon.com (Nate Amsden) Date: Tue Jun 11 14:07:01 2002 Subject: [eepro100] eth0: card reports no resources - can you help me identify which version of this problem I'm having? In-Reply-To: <66974D92E0A57741A23D3876BF6806410EF7DB@mail.appliedepi.com> References: <66974D92E0A57741A23D3876BF6806410EF7DB@mail.appliedepi.com> Message-ID: <3487.10.50.1.2.1023686166.squirrel@webmail-wa.graphon.com> Robert Fentiman said: > After looking through the ML archives, I know you're probably tired > of hearing this one, but even so I would appreciate your help in > tracking down which version of the cause and possible solution for > the problem I'm seeing. while i don't have a solution, i have a workaround that works for me. when this happens if I reset the interface (on debian via /etc/init.d/networking restart) it fixes the problem. I have a similar issue on 3COM 3C905 cards, different error message, but same result, and the same workaround works. wish i had a full solution. luckily I have only encountered this problem on the eepro cards that i have(i have about 2 dozen of them in servers) 3-4 times in the past year, and on the 3com cards, 3-4 times(on the same server). on my personal server which has dual 3c905b's (only 1 is in use), i had to setup a script to search the log for the error message and restart networking if it finds it. since it seems to happen at random once every 2-3 months. in all instances the driver is compiled into the kernel, not sure if the situation would be different if it was modularized. nate -- Nate Amsden System Administrator GraphOn (Sent using Squirrelmail! 1.2.4) From steve@extex.com Tue Jun 11 21:17:00 2002 From: steve@extex.com (Steve Keith) Date: Tue Jun 11 20:17:00 2002 Subject: [eepro100] Compile problems In-Reply-To: <001701c21023$97ef7e30$a808a8c0@CODINGMAN> Message-ID: <5.1.0.14.0.20020611110427.00a2c3a0@linuxbox2> Background: Tyan Tiger 200T w/dual Intel 82559 controllers. RH7.2 detected them as 82557 eepro100 and installed the RH7.2 eepro100.o driver. The server "fell off" the network within a few hours during a backup operation across the network. ifconfig reported: eth0 Link encap:Ethernet HWaddr 00:E0:81:21:2A:DC inet addr:192.168.100.200 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3625486 errors:0 dropped:0 overruns:0 frame:0 TX packets:3650831 errors:0 dropped:0 overruns:212 carrier:0 collisions:0 txqueuelen:100 RX bytes:3909460367 (3728.3 Mb) TX bytes:1961718651 (1870.8 Mb) Interrupt:5 Base address:0x1000 "/etc/init.d/network restart" would not restore network function. /proc/pci reports them as 85227 chips: Bus 0, device 13, function 0: Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8). IRQ 5. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xf6222000 [0xf6222fff]. I/O at 0xe400 [0xe43f]. Non-prefetchable 32 bit memory at 0xf6000000 [0xf60fffff]. Bus 0, device 14, function 0: Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#2) (rev 8). IRQ 10. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xf6221000 [0xf6221fff]. I/O at 0xe800 [0xe83f]. Non-prefetchable 32 bit memory at 0xf6100000 [0xf61fffff]. I download the e100.o driver from the Intel website. Installation was smooth, and it stayed up for about a week. Then, it just fell off the network again... couldn't access it from win98 machines (Samba, ssh, etc)... just like before except that ifconfig showed no overruns. I could still log into the server directly. I tried "/etc/init.d/network restart", but no network communication could be had. I rebooted the system and now it's up and running again. As another shot in the dark, I decided to try the scyld driver. I downloaded: eepro100.c kern_compat.h pci-scan.c pci-scan.h I compiled: pci-scan.o using the command at the end of pci-scan.c "gcc -DMODULE -D__KERNEL__ -O6 -c eepro100.c" results in: In file included from eepro100.c:97: /usr/include/linux/modversions.h:1:2: #error Modules should never use kernel-headers system headers, /usr/include/linux/modversions.h:2:2: #error but rather headers from an appropriate kernel-source package. /usr/include/linux/modversions.h:3:2: #error Change -I/usr/src/linux/include (or similar) to /usr/include/linux/modversions.h:4:2: #error -I/lib/modules/$(uname -r)/build/include /usr/include/linux/modversions.h:5:2: #error to build against the currently-running kernel. I recompiled incorporating the suggestions given and there were no errors. "insmod eepro100.o" results in: eepro100.o: unresolved symbol acpi_set_pwr_state eepro100.o: unresolved symbol pci_drv_unregister eepro100.o: unresolved symbol pci_drv_register Manually moving the eepro100.o file into /lib/modules/2.4.7-10enterprise/kernel/drivers/net and adding the appropriate alias in /etc/modules.conf causes failed dependencies at startup and eth0 will not come up. The system is currently running on the Intel drivers, 356MB TX, just counting until the next failure! Any suggestions on getting this driver to work or other tools/techniques to track down flaky network card performance will be greatly appreciated. Thanks, Steve From Russ_Brett@emc.com Tue Jun 11 21:50:00 2002 From: Russ_Brett@emc.com (Russ_Brett@emc.com) Date: Tue Jun 11 20:50:00 2002 Subject: [eepro100] Compile problems Message-ID: <93F527C91A6ED411AFE10050040665D00502CDB7@corpusmx1.us.dg.com> You can try the following to get the Scyld driver running; I had some of the same troubles and found the answer after searching around the net a while: -I try to build the driver on the kernel that I am going to run the driver on. I don't know if this is a necessity but it can't hurt and probably helps. -Put the Scyld source files into /usr/src/linux-xxx/drivers/net/ -- Save your old eepro100.c if desired. -Edit the Makefile in that dir as follows: -Add pci-scan.o to the end of the "export-objs" line; mii.o should be in there too for example. -Add pci-scan.o to the end of the "obj-$(CONFIG_EEPRO100)" line; mii.o appears there as well in mine. -from /usr/src/linux-xxx/ run 'make clean dep bzImage modules modules_install' -you'll notice that pci-scan.o now should appear in /lib/modules/xxx/modules.dep under eepro100.o and that both of those obj files should be under kernel/drivers/net/ in the modules tree. -When you load the module, pci-scan.o will be loaded automatically This is from memory and relates to 2.4.19-pre10 so I hope I didn't miss any steps. good luck, brett -----Original Message----- From: Steve Keith [mailto:steve@extex.com] Sent: Tuesday, June 11, 2002 8:18 PM To: eepro100@scyld.com Subject: [eepro100] Compile problems Background: Tyan Tiger 200T w/dual Intel 82559 controllers. RH7.2 detected them as 82557 eepro100 and installed the RH7.2 eepro100.o driver. The server "fell off" the network within a few hours during a backup operation across the network. ifconfig reported: eth0 Link encap:Ethernet HWaddr 00:E0:81:21:2A:DC inet addr:192.168.100.200 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3625486 errors:0 dropped:0 overruns:0 frame:0 TX packets:3650831 errors:0 dropped:0 overruns:212 carrier:0 collisions:0 txqueuelen:100 RX bytes:3909460367 (3728.3 Mb) TX bytes:1961718651 (1870.8 Mb) Interrupt:5 Base address:0x1000 "/etc/init.d/network restart" would not restore network function. /proc/pci reports them as 85227 chips: Bus 0, device 13, function 0: Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8). IRQ 5. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xf6222000 [0xf6222fff]. I/O at 0xe400 [0xe43f]. Non-prefetchable 32 bit memory at 0xf6000000 [0xf60fffff]. Bus 0, device 14, function 0: Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#2) (rev 8). IRQ 10. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xf6221000 [0xf6221fff]. I/O at 0xe800 [0xe83f]. Non-prefetchable 32 bit memory at 0xf6100000 [0xf61fffff]. I download the e100.o driver from the Intel website. Installation was smooth, and it stayed up for about a week. Then, it just fell off the network again... couldn't access it from win98 machines (Samba, ssh, etc)... just like before except that ifconfig showed no overruns. I could still log into the server directly. I tried "/etc/init.d/network restart", but no network communication could be had. I rebooted the system and now it's up and running again. As another shot in the dark, I decided to try the scyld driver. I downloaded: eepro100.c kern_compat.h pci-scan.c pci-scan.h I compiled: pci-scan.o using the command at the end of pci-scan.c "gcc -DMODULE -D__KERNEL__ -O6 -c eepro100.c" results in: In file included from eepro100.c:97: /usr/include/linux/modversions.h:1:2: #error Modules should never use kernel-headers system headers, /usr/include/linux/modversions.h:2:2: #error but rather headers from an appropriate kernel-source package. /usr/include/linux/modversions.h:3:2: #error Change -I/usr/src/linux/include (or similar) to /usr/include/linux/modversions.h:4:2: #error -I/lib/modules/$(uname -r)/build/include /usr/include/linux/modversions.h:5:2: #error to build against the currently-running kernel. I recompiled incorporating the suggestions given and there were no errors. "insmod eepro100.o" results in: eepro100.o: unresolved symbol acpi_set_pwr_state eepro100.o: unresolved symbol pci_drv_unregister eepro100.o: unresolved symbol pci_drv_register Manually moving the eepro100.o file into /lib/modules/2.4.7-10enterprise/kernel/drivers/net and adding the appropriate alias in /etc/modules.conf causes failed dependencies at startup and eth0 will not come up. The system is currently running on the Intel drivers, 356MB TX, just counting until the next failure! Any suggestions on getting this driver to work or other tools/techniques to track down flaky network card performance will be greatly appreciated. Thanks, Steve _______________________________________________ eepro100 mailing list eepro100@scyld.com http://www.scyld.com/mailman/listinfo/eepro100 From becker@scyld.com Tue Jun 11 22:23:00 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jun 11 21:23:00 2002 Subject: [eepro100] eth0: card reports no resources - can you help me identify which version of this problem I'm having? In-Reply-To: <3487.10.50.1.2.1023686166.squirrel@webmail-wa.graphon.com> Message-ID: On Sun, 9 Jun 2002, Nate Amsden wrote: > Robert Fentiman said: > > After looking through the ML archives, I know you're probably > tired > > of hearing this one, but even so I would appreciate your help in > > tracking down which version of the cause and possible solution for > > the problem I'm seeing. > > while i don't have a solution, i have a workaround that > works for me. when this happens if I reset the interface > (on debian via /etc/init.d/networking restart) it fixes the > problem. I have a similar issue on 3COM 3C905 cards, different > error message, but same result, and the same workaround works. If the problem is that the kernel is running short of memory, even though the machine has plenty of RAM, try the tuning the VM parameters: 2.2 kernels echo 500 1000 2000 > /proc/sys/vm/freepages and 2.4 kernels echo "100 500 200" > /proc/sys/vm/bdflush I suggested this recently on this mailing list... (searching...) April 24, 2002 -- 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 spitko@hotmail.com Wed Jun 12 11:42:03 2002 From: spitko@hotmail.com (Sami Pitko) Date: Wed Jun 12 10:42:03 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c and 2.2.14-5.0smp Message-ID: Hello, I am having problems with pci-scan.c in stock RedHat 6.2 (2.2.14-5.0smp) running on SMP hardware. Compiling with command: gcc -DMODULE -D__KERNEL__ -D__SMP__ -DEXPORT_SYMTAB \ -Wall -Wstrict-prototypes -O6 -c pci-scan.c gives no errors nor warnings. insmod pci-scan.o gives: pci-scan.o: unresolved symbol apm_register_callback_Rsmpf70b592f pci-scan.o: unresolved symbol apm_unregister_callback_Rsmp99700428 Everything works just fine with 2.2.14-5.0 without SMP (on a non-SMP machine). Any ideas? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From becker@scyld.com Wed Jun 12 12:37:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 12 11:37:01 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c and 2.2.14-5.0smp In-Reply-To: Message-ID: On Wed, 12 Jun 2002, Sami Pitko wrote: > Subject: [eepro100] Unresolved symbols, pci-scan.c and 2.2.14-5.0smp > > I am having problems with pci-scan.c in stock RedHat 6.2 (2.2.14-5.0smp) > running on SMP hardware. I suspect this problem is with the header files in your installation.. > gcc -DMODULE -D__KERNEL__ -D__SMP__ -DEXPORT_SYMTAB \ > -Wall -Wstrict-prototypes -O6 -c pci-scan.c > insmod pci-scan.o gives: > > pci-scan.o: unresolved symbol apm_register_callback_Rsmpf70b592f > pci-scan.o: unresolved symbol apm_unregister_callback_Rsmp99700428 The APM calls are enabled only when defined(CONFIG_APM) && LINUX_VERSION_CODE < 0x20400 Your header files are declaring that your kernel has APM support, but you don't have the kernel entry points for APM support. The immediate work-around is to add -UCONFIG_APM to the compile line. The correct solution is to figure out why the CONFIG_APM symbol is being defined in /usr/include/linux/autoconf.h -- 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 subscriptions@graphon.com Wed Jun 12 14:58:00 2002 From: subscriptions@graphon.com (Nate Amsden) Date: Wed Jun 12 13:58:00 2002 Subject: [eepro100] eth0: card reports no resources - can you help meidentify which version of this problem I'm having? References: Message-ID: <3D078B5C.D55F7E02@graphon.com> Donald Becker wrote: > > If the problem is that the kernel is running short of memory, even > though the machine has plenty of RAM, try the tuning the VM parameters: yeah i remember that, what is the potential pitfalls if any of changing the parameters? I have never tuned the vm for linux before. I read the docs(Documentation/sysctl/vm.txt) from the source on it, but they didn't explain to me what good values were to be. also, is there any benefit for making it higher? or downside? I run 2.2 kernels on all my systems. mainly I am interested in is would it it severely affect performance, stability, other things (like SCSI and/or IDE controllers). I suppose in theory i could increase freepages.high to some absurd number to make sure theres always plenty of memory, but then the question is how much memory is in a page? most of my systems operate with 3-4 times the minimum amount of physical memory to do their tasks..(i'll stop because its getting a bit off topic :) ) Maybe this could affect SCSI buffers? I have a problem on another system with 3 DLT tape drives, even after tuning the scsi buffers in the kernel and recompiling, i still get cannot allocate buffer errors(even with 768MB ram). maybe it will help the 3com problem too.. maybe there is a book or document somewhere that describes scenarios and how best to tune for them.. thanks donald for great drivers!! nate -- Nate Amsden System Administrator GraphOn http://www.graphon.com From becker@scyld.com Wed Jun 12 15:59:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 12 14:59:00 2002 Subject: [eepro100] eth0: card reports no resources - can you help meidentify which version of this problem I'm having? In-Reply-To: <3D078B5C.D55F7E02@graphon.com> Message-ID: On Wed, 12 Jun 2002, Nate Amsden wrote: > > If the problem is that the kernel is running short of memory, even > > though the machine has plenty of RAM, try the tuning the VM parameters: > > yeah i remember that, what is the potential pitfalls if any of changing > the parameters? I have never tuned the vm for linux before. I read the > docs(Documentation/sysctl/vm.txt) from the source on it, but they didn't > explain to me what good values were to be. I someone convincingly knew what the correct values were, they would be changed in the kernel. The kernels before 2.2 did a much better job of keeping an adequate amount of free memory for the network stack. The 2.2 and 2.4 kernels have different behaviors, but both are much more likely to temporarily run short or memory, even (especially) with much RAM and swap space. > also, is there any benefit for making it higher? or downside? The downside is going too far. You can have the kernel reserve 60MB of 64MB for its own use, allowing too little for any application to run. The VM settings for most 2.2 kernel seems to be oriented to 16MB machines. Most machines have more memory, and are better served with higher kernel-reserve settings. > I run 2.2 > kernels on all my systems. mainly I am interested in is would it > it severely affect performance, stability, other things (like SCSI and/or IDE > controllers). A moderate increase should help most subsystems. > recompiling, i still get cannot allocate buffer errors(even with > 768MB ram). With 768MB RAM, you should definitely increase the kernel-reserve memory parameter. -- 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 Jun 12 18:17:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 12 17:17:01 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c and 2.2.14-5.0smp In-Reply-To: Message-ID: On Thu, 13 Jun 2002, Sami Pitko wrote: > Subject: Re: [eepro100] Unresolved symbols, pci-scan.c and 2.2.14-5.0smp > > >The immediate work-around is to add -UCONFIG_APM to the compile line. > > Unfortunately this did not work. OK... > >The correct solution is to figure out why the CONFIG_APM symbol is > >being defined in > > /usr/include/linux/autoconf.h > > Here's output of > 'grep CONFIG_APM /usr/src/linux-2.2.14/include/linux/autoconf-smp.h': > > #define CONFIG_APM 1 ... > #define CONFIG_APM_POWER_OFF 1 > #define CONFIG_APM_RTC_IS_GMT 1 Could you look at the lines in the file around these lines to see why CONFIG_APM is set? The "autoconf-smp.h" file should match the SMP kernel. > I modified the 'define' lines to 'undef' and it compiles and insmods without > any errors. Thank you very much. We still want to track down the general problem to automatically fix it for other users. -- 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 spitko@hotmail.com Wed Jun 12 18:22:03 2002 From: spitko@hotmail.com (Sami Pitko) Date: Wed Jun 12 17:22:03 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c and 2.2.14-5.0smp Message-ID: >The immediate work-around is to add -UCONFIG_APM to the compile line. Unfortunately this did not work. >The correct solution is to figure out why the CONFIG_APM symbol is >being defined in > /usr/include/linux/autoconf.h Here's output of 'grep CONFIG_APM /usr/src/linux-2.2.14/include/linux/autoconf-smp.h': #define CONFIG_APM 1 #undef CONFIG_APM_IGNORE_USER_SUSPEND #undef CONFIG_APM_DO_ENABLE #undef CONFIG_APM_CPU_IDLE #undef CONFIG_APM_DISPLAY_BLANK #define CONFIG_APM_POWER_OFF 1 #undef CONFIG_APM_IGNORE_MULTIPLE_SUSPEND #undef CONFIG_APM_IGNORE_SUSPEND_BOUNCE #define CONFIG_APM_RTC_IS_GMT 1 #undef CONFIG_APM_ALLOW_INTS I modified the 'define' lines to 'undef' and it compiles and insmods without any errors. Thank you very much. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From spitko@hotmail.com Thu Jun 13 14:43:01 2002 From: spitko@hotmail.com (Sami Pitko) Date: Thu Jun 13 13:43:01 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c and 2.2.14-5.0smp Message-ID: > > #define CONFIG_APM 1 >... > > #define CONFIG_APM_POWER_OFF 1 > > #define CONFIG_APM_RTC_IS_GMT 1 > >Could you look at the lines in the file around these lines to see why >CONFIG_APM is set? The "autoconf-smp.h" file should match the SMP >kernel. >We still want to track down the general problem to automatically fix it >for other users. First lines of the autoconf-smp.h says: /* * Automatically generated C config: don't edit */ CONFIG_APM is in section General setup, which has following lines: /* * General setup */ #undef CONFIG_BIGMEM #define CONFIG_NET 1 #define CONFIG_PCI 1 #undef CONFIG_PCI_GOBIOS #undef CONFIG_PCI_GODIRECT #define CONFIG_PCI_GOANY 1 #define CONFIG_PCI_BIOS 1 #define CONFIG_PCI_DIRECT 1 #define CONFIG_PCI_QUIRKS 1 #undef CONFIG_PCI_OPTIMIZE #define CONFIG_PCI_OLD_PROC 1 #undef CONFIG_MCA #undef CONFIG_VISWS #define CONFIG_X86_IO_APIC 1 #define CONFIG_X86_LOCAL_APIC 1 #define CONFIG_SYSVIPC 1 #define CONFIG_BSD_PROCESS_ACCT 1 #define CONFIG_SYSCTL 1 #undef CONFIG_BINFMT_AOUT #define CONFIG_BINFMT_AOUT_MODULE 1 #define CONFIG_BINFMT_ELF 1 #undef CONFIG_BINFMT_MISC #define CONFIG_BINFMT_MISC_MODULE 1 #undef CONFIG_BINFMT_JAVA #define CONFIG_BINFMT_JAVA_MODULE 1 #undef CONFIG_PARPORT #define CONFIG_PARPORT_MODULE 1 #undef CONFIG_PARPORT_PC #define CONFIG_PARPORT_PC_MODULE 1 #undef CONFIG_PARPORT_OTHER #define CONFIG_APM 1 #undef CONFIG_APM_IGNORE_USER_SUSPEND #undef CONFIG_APM_DO_ENABLE #undef CONFIG_APM_CPU_IDLE #undef CONFIG_APM_DISPLAY_BLANK #define CONFIG_APM_POWER_OFF 1 #undef CONFIG_APM_IGNORE_MULTIPLE_SUSPEND #undef CONFIG_APM_IGNORE_SUSPEND_BOUNCE #define CONFIG_APM_RTC_IS_GMT 1 #undef CONFIG_APM_ALLOW_INTS After those lines there are definitions for Plug and Play support and so on. The machine has following kernel rpms installed (these are outdated with known security holes, but they come from the RH6.2 CD by default): # rpm -qa|grep kernel kernel-2.2.14-5.0 kernel-pcmcia-cs-2.2.14-5.0 kernel-smp-2.2.14-5.0 kernel-utils-2.2.14-5.0 kernel-headers-2.2.14-5.0 autoconf-smp.h file is part of kernel-headers rpm: # rpm -ql kernel-headers|grep autoconf-smp.h /usr/src/linux-2.2.14/include/linux/autoconf-smp.h I have not tested compilation/insmod with latest RH supplied kernel (2.2.19-6.2.16) for RH6.2 as I don't have a spare SMP machine for testing. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From j.radinger@phion.com Thu Jun 13 14:46:55 2002 From: j.radinger@phion.com (Joe Radinger) Date: Thu Jun 13 13:46:55 2002 Subject: [eepro100] should i be worried about my eepro cards Message-ID: <1023962136.8302.41.camel@yoda> --=-wdx7EE+AVEIT0a4yaDwM Content-Type: multipart/mixed; boundary="=-5AZBfMvmkxd0Ug7PRj0Z" --=-5AZBfMvmkxd0Ug7PRj0Z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable have such a system: 33Mhz pci + 66Mhz pci 4*dualport eepro100 cards (two on 33Mhz, two on 66Mhz) 1 onboard eepro100 dmesg states: eepro100.c:v1.17a 8/7/2001 Donald Becker http://www.scyld.com/network/eepro100.html divert: allocating divert_blk for eth0 eth0: Intel PCI EtherExpress Pro100 at 0xa0042000, 00:09:6B:B0:21:55, IRQ 11. Board assembly ffffff-255, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x3258698e). divert: allocating divert_blk for eth1 eth1: Intel PCI EtherExpress Pro100 at 0xa0044000, 00:02:B3:A9:A2:F9, IRQ 15. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). divert: allocating divert_blk for eth2 eth2: Intel PCI EtherExpress Pro100 at 0xa0046000, 00:02:B3:A9:A2:FA, IRQ 3. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). divert: allocating divert_blk for eth3 eth3: Intel PCI EtherExpress Pro100 at 0xa0048000, 00:02:B3:A9:A5:E7, IRQ 4. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). divert: allocating divert_blk for eth4 eth4: Intel PCI EtherExpress Pro100 at 0xa004a000, 00:02:B3:A9:A5:E8, IRQ 10. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). divert: allocating divert_blk for eth5 eth5: Invalid EEPROM checksum 0x5773, check settings before activating this device! eth5: Intel PCI EtherExpress Pro100 at 0xa004c000, FF:FF:B3:A9:FF:FF, IRQ 11. Board assembly ffff31-002, Physical connectors present: RJ45 Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). divert: allocating divert_blk for eth6 eth6: Invalid EEPROM checksum 0x5673, check settings before activating this device! eth6: Intel PCI EtherExpress Pro100 at 0xa004e000, FF:FF:B3:A9:FF:FF, IRQ 15. Board assembly ffff31-002, Physical connectors present: RJ45 Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). divert: allocating divert_blk for eth7 eth7: Invalid EEPROM checksum 0x1d72, check settings before activating this device! eth7: Intel PCI EtherExpress Pro100 at 0xa0050000, FF:FF:B3:A9:FF:FF, IRQ 3. Board assembly ffff31-002, Physical connectors present: RJ45 Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). divert: allocating divert_blk for eth8 eth8: Invalid EEPROM checksum 0x1c72, check settings before activating this device! eth8: Intel PCI EtherExpress Pro100 at 0xa0052000, FF:FF:B3:A9:FF:FF, IRQ 4. Board assembly ffff31-002, Physical connectors present: RJ45 Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xb874c1d3). what does this "check settings" mean? attached is the output from eepro100-diag -a -e -m -f yours josef --=-5AZBfMvmkxd0Ug7PRj0Z Content-Disposition: attachment; filename=diagnose.txt Content-Type: text/plain; name=diagnose.txt; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x4000. i82557 chip registers at 0x4000: 00000050 1f4d48ec 00000000 00080002 18250081 00000600 No interrupt sources are pending. The transmit unit state is 'Suspended'. The receive unit state is 'Ready'. This status is normal for an activated but idle interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:09:6B:B0:21:55. Board assembly ffffff-255, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 782d 02a8 0154 05e1 0081 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0a02 0000 0001 0000 0000 0000 0000 0000 0000 0000 0b10 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 782d 02a8 0154 05e1 0081 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0a02 0000 0001 0000 0000 0000 0000 0000 0000 0000 0b10 0000 0010 0000 0000 0000. 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:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0081: 100baseTx. Negotiation did not complete. Index #2: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x3000. i82557 chip registers at 0x3000: 00000050 1eaff0ec 00000000 00080002 18250000 00000600 No interrupt sources are pending. The transmit unit state is 'Suspended'. The receive unit state is 'Ready'. This status is normal for an activated but idle interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A2:F9. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0880 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0880 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Index #3: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x3040. i82557 chip registers at 0x3040: 00000050 1eafe8ec 00000000 00080002 18250000 00000600 No interrupt sources are pending. The transmit unit state is 'Suspended'. The receive unit state is 'Ready'. This status is normal for an activated but idle interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A2:FA. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 09f0 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0de0 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Index #4: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x2000. i82557 chip registers at 0x2000: 00000050 1eafe0ec 00000000 00080002 18250000 00000600 No interrupt sources are pending. The transmit unit state is 'Suspended'. The receive unit state is 'Ready'. This status is normal for an activated but idle interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A5:E7. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 08d0 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 09d0 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Index #5: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x2040. i82557 chip registers at 0x2040: 00000050 1e9598ec 00000000 00080002 18250000 00000600 No interrupt sources are pending. The transmit unit state is 'Suspended'. The receive unit state is 'Ready'. This status is normal for an activated but idle interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A5:E8. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0890 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0890 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Index #6: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x6000. i82557 chip registers at 0x6000: 00000000 00000000 00000000 00080002 18250000 00000000 No interrupt sources are pending. The transmit unit state is 'Idle'. The receive unit state is 'Idle'. This status is unusual for an activated interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A3:9B. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0de0 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 09f0 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Index #7: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x6040. i82557 chip registers at 0x6040: 00000000 00000000 00000000 00080002 18250000 00000000 No interrupt sources are pending. The transmit unit state is 'Idle'. The receive unit state is 'Idle'. This status is unusual for an activated interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A3:9C. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0890 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0890 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Index #8: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x5000. i82557 chip registers at 0x5000: 00000000 00000000 00000000 00080002 18250000 00000000 No interrupt sources are pending. The transmit unit state is 'Idle'. The receive unit state is 'Idle'. This status is unusual for an activated interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A4:D5. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0de0 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 09f0 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Index #9: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0= x5040. i82557 chip registers at 0x5040: 00000000 00000000 00000000 00080002 18250000 00000000 No interrupt sources are pending. The transmit unit state is 'Idle'. The receive unit state is 'Idle'. This status is unusual for an activated interface. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:A9:A4:D6. Board assembly a56831-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555, PHY -1. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0880 0000 0010 0000 0000 0000. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0880 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10bas= eT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. --=-5AZBfMvmkxd0Ug7PRj0Z-- --=-wdx7EE+AVEIT0a4yaDwM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9CGwYyOLl//lX6PMRAj6QAJ4kYt2pN/UiSX5XiHdilyzC4vOmNACfSXaJ yU3qDfuLM92x1bqW+kx8wew= =tR9D -----END PGP SIGNATURE----- --=-wdx7EE+AVEIT0a4yaDwM-- From becker@scyld.com Thu Jun 13 16:18:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jun 13 15:18:01 2002 Subject: [eepro100] should i be worried about my eepro cards In-Reply-To: <1023962136.8302.41.camel@yoda> Message-ID: On 13 Jun 2002, Joe Radinger wrote: > Subject: [eepro100] should i be worried about my eepro cards Yes. > 33Mhz pci + 66Mhz pci > 4*dualport eepro100 cards (two on 33Mhz, two on 66Mhz) > 1 onboard eepro100 > > eepro100.c:v1.17a 8/7/2001 Donald Becker > http://www.scyld.com/network/eepro100.html > divert: allocating divert_blk for eth0 Presumably you are running a patched kernel to have the divert code... > eth0: Intel PCI EtherExpress Pro100 at 0xa0042000, 00:09:6B:B0:21:55, > Board assembly ffffff-255, Physical connectors present: RJ45 This must be the on-board NIC? Usually that's at the end of bus 0 > eth1: Intel PCI EtherExpress Pro100 at 0xa0044000, 00:02:B3:A9:A2:F9, > Board assembly a56831-002, Physical connectors present: RJ45 > eth2: Intel PCI EtherExpress Pro100 at 0xa0046000, 00:02:B3:A9:A2:FA, > Board assembly a56831-002, Physical connectors present: RJ45 One pair, good detection. > eth3: Intel PCI EtherExpress Pro100 at 0xa0048000, 00:02:B3:A9:A5:E7, > Board assembly a56831-002, Physical connectors present: RJ45 > eth4: Intel PCI EtherExpress Pro100 at 0xa004a000, 00:02:B3:A9:A5:E8, > Board assembly a56831-002, Physical connectors present: RJ45 Same type of board > eth5: Invalid EEPROM checksum 0x5773, check settings before activating > this device! Ohhh, bad news. > eth5: Intel PCI EtherExpress Pro100 at 0xa004c000, FF:FF:B3:A9:FF:FF, Bad station address. All other information is suspect. Do not activate this device. > Board assembly ffff31-002, Physical connectors present: RJ45 > Primary interface chip unknown-15 PHY #31. This will prevent the NIC from working correctly. > eth6: Invalid EEPROM checksum 0x5673, check settings before activating > this device! > eth6: Intel PCI EtherExpress Pro100 at 0xa004e000, FF:FF:B3:A9:FF:FF, > IRQ 15. > eth7: Invalid EEPROM checksum 0x1d72, check settings before activating > this device! > eth7: Intel PCI EtherExpress Pro100 at 0xa0050000, FF:FF:B3:A9:FF:FF, > eth8: Invalid EEPROM checksum 0x1c72, check settings before activating > this device! > eth8: Intel PCI EtherExpress Pro100 at 0xa0052000, FF:FF:B3:A9:FF:FF, > attached is the output from eepro100-diag -a -e -m -f Hmmm, the diag program didn't have a problem reading the EEPROM. Which interfaces are on the 66Mhz bus? I've tested the driver with a 66Mhz PCI bus, but there might be some timing issue. Or this might just be a bus bridge issue. Try compiling the driver with the additional flag -DUSE_IO_OPS -- 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 gman@gman.infinex.com Thu Jun 13 21:38:00 2002 From: gman@gman.infinex.com (G-man) Date: Thu Jun 13 20:38:00 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 Message-ID: <006701c2133b$bf0577c0$2224040a@hq.spinner.com> think Sami Pitko spitko@hotmail.com is having about the same problem This is a redhat 6.2 box running 2.2.19-6.2.16enterprise. Box is completely up todate with its rpms.. kernel-enterprise-2.2.19-6.2.16 kernel-headers-2.2.19-6.2.16 kernel-smp-2.2.19-6.2.16 kernel-utils-2.2.19-6.2.16 kernel-enterprise-2.2.19-6.2.16 kernel-source-2.2.19-6.2.16 I download the eepro100.c and pci-scan.c yesterday.. I compiled modules like this: gcc -I/usr/src/linux/include -I/usr/src/linux/include/linux/modversions.h -D MODULE -D__KERNEL__ -DEXPORT_SYMTAB -O6 -c pci-scan.c gcc -I/usr/src/linux/include -I/usr/src/linux/include/linux/modversions.h -D MODULE -D__KERNEL__ -DEXPORT_SYMTAB -O6 -c eepro100.c compiles without error.. then I insmod pci-scan.c and get: /sbin/insmod pci-scan Using /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol __ioremap_R9eac042a /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_find_class_R6c460806 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_write_config_word_Rd9cc3b03 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_write_config_dword_Rf0fbd200 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_read_config_dword_R2ca7e89f /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol kmalloc_R93d4cfe6 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_read_config_byte_Re5ceea13 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol apm_register_callback_Rf70b592f /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_write_config_byte_Re84d5397 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol check_region_R522f4d72 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_set_master_R040f6432 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol kfree_R037a0cba /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol printk_R1b7d4074 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol apm_unregister_callback_R99700428 /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol pci_read_config_word_R8764d15f I tried that -UAPM_CONFIG but get the same error.. autoconf-smp.h doesn't exist.. like Sami I tried change the define lines to undef .. but I didn't have any luck doing that... From so500000c@yahoo.com Fri Jun 14 00:12:01 2002 From: so500000c@yahoo.com (so so) Date: Thu Jun 13 23:12:01 2002 Subject: [eepro100] Urgent and confidential. Message-ID: <20020614031149.90265.qmail@web21008.mail.yahoo.com> 3/5 RIDER HAGGARD CLOSE, JO, BORG SOUTH AFRICA. Email: Bobbyeste.Baker@xmail.com. {URGENT AND CONFIDENTIAL) (RE: TRANSFER OF ($ 152,000.000.00 USD ONE HUNDRED AND FIFTY TWO MILLION DOLLARS ) Dear sir, We want to transfer to overseas ($ 152,000.000.00 USD) One hundred and Fifty two million United States Dollars) from a Bank in Africa, I want to ask you to quietly look for a reliable and honest person who will be capable and fit to provide either an existing bank account or to set up a new Bank a/c immediately to receive this money, even an empty a/c can serve to receive this money, as long as you will remain honest to me till the end for this important business trusting in you and believing in God that you will never let me down either now or in future. I am Mr Peter Vann, the Auditor General of a bank in Africa, during the course of our auditing I discovered a floating fund in an account opened in the bank in 1990 and since 1993 nobody has operated on this account again, after going through some old files in the records I discovered that the owner of the account died without a [heir] hence the money is floating and if I do not remit this money out urgently it will be forfeited for nothing. the owner of this account is Mr. Magnus leon, a foreigner, and a sailor, and he died, since 1993. and no other person knows about this account or any thing concerning it, the account has no other beneficiary and my investigation proved to me as well that Magnus Leon until his death was the manager Magnus Coy.(pty). SA. We will start the first transfer with fifty two million [$52,000.000] upon successful transaction without any disappoint from your side, we shall re-apply for the payment of the remaining rest amount to your account. The amount involved is (USD 152M) One hundred and Fifty two million United States Dollars, only I want to first transfer $52,000.000 [fifty two million United States Dollar from this money into a safe foreigners account abroad before the rest, but I don't know any foreigner, I am only contacting you as a foreigner because this money can not be approved to a local person here, without valid international foreign passport, but can only be approved to any foreigner with valid international passport or drivers license and foreign a/c because the money is in us dPOST http://us.f203.mail.yahoo.com/ym/Compose?YY=19893 HTTP/1.0ollars and the former owner of the a/c Mr. Magnus Leon is a foreigner too, [and the money can only be approved into a foreign a/c. However, we will sign a binding agreement, to bind us together I got your contact address from the Girl who operates computer, I am revealing this to you with believe in God that you will never let me down in this business, you are the first and the only person that I am contacting for this business, so please reply urgently so that I will inform you the next step to take urgently. Send also your private telephone and fax number including the full details of the account to be used for the deposit. I want us to meet face to face to build confidence and to sign a binding agreement that will bind us together before transferring the money to any account of your choice where the fund will be safe. Before we fly to your country for withdrawal, sharing and investments. I need your full co-operation to make this work fine. because the management is ready to approve this payment to any foreigner who has correct information of this account, which I will give to you, upon your positive response and once I am convinced that you are capable and will meet up with instruction of a key bank official who is deeply involved with me in this business. I need your strong assurance that you will never, never let me down. With my influence and the position of the bank official we can transfer this money to any foreigner's reliable account which you can provide with assurance that this money will be intact pending our physical arrival in your country for sharing. The bank official will destroy all documents of transaction immediately we receive this money leaving no trace to any place and to build confidence you can come immediately to discuss with me face to face after which I will make this remittance in your presence and three of us will fly to your country at least two days ahead of the money going into the account. I will apply for annual leave to get visa immediately I hear from you that you are ready to act and receive this fund in your account. I will use my position and influence to obtain all legal approvals for onward transfer of this money to your account with appropriate clearance from the relevant ministries and foreign exchange departments. At the conclusion of this business, you will be given 35% of the total amount, 60% will be for me, while 5% will be for expenses both parties might have incurred during the process of transferring. I look forward to your earliest reply through my email address: Bobbyeste.Baker@xmail.com. Your, Peter Vann __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From gman@gman.infinex.com Fri Jun 14 16:37:01 2002 From: gman@gman.infinex.com (G-man) Date: Fri Jun 14 15:37:01 2002 Subject: [eepro100] FIXED - Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 References: <006701c2133b$bf0577c0$2224040a@hq.spinner.com> Message-ID: <000b01c213da$e99a5880$2224040a@hq.spinner.com> I compiled both pci-scan.c and eepro100.c with: gcc -D__module__enterprise -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -Wall -Ws trict-prototypes -O6 -c eepro100.c gcc -D__module__enterprise -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -Wall -Ws trict-prototypes -O6 -c pci-scan.c and it got rid of all the errors.. I was running the enterprise kernel.. ----- Original Message ----- From: "G-man" To: Sent: Thursday, June 13, 2002 5:38 PM Subject: [eepro100] Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 > think Sami Pitko spitko@hotmail.com is having about the same problem > > This is a redhat 6.2 box running 2.2.19-6.2.16enterprise. Box is completely > up todate with its rpms.. > > kernel-enterprise-2.2.19-6.2.16 > kernel-headers-2.2.19-6.2.16 > kernel-smp-2.2.19-6.2.16 > kernel-utils-2.2.19-6.2.16 > kernel-enterprise-2.2.19-6.2.16 > kernel-source-2.2.19-6.2.16 > > I download the eepro100.c and pci-scan.c yesterday.. > I compiled modules like this: > gcc -I/usr/src/linux/include -I/usr/src/linux/include/linux/modversions.h -D > MODULE -D__KERNEL__ -DEXPORT_SYMTAB -O6 -c pci-scan.c > > gcc -I/usr/src/linux/include -I/usr/src/linux/include/linux/modversions.h -D > MODULE -D__KERNEL__ -DEXPORT_SYMTAB -O6 -c eepro100.c > > compiles without error.. then I insmod pci-scan.c and get: > > /sbin/insmod pci-scan > Using /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > __ioremap_R9eac042a > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_find_class_R6c460806 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_write_config_word_Rd9cc3b03 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_write_config_dword_Rf0fbd200 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_read_config_dword_R2ca7e89f > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > kmalloc_R93d4cfe6 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_read_config_byte_Re5ceea13 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > apm_register_callback_Rf70b592f > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_write_config_byte_Re84d5397 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > check_region_R522f4d72 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_set_master_R040f6432 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > kfree_R037a0cba > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > printk_R1b7d4074 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > apm_unregister_callback_R99700428 > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > pci_read_config_word_R8764d15f > > I tried that -UAPM_CONFIG but get the same error.. > autoconf-smp.h doesn't exist.. > > > like Sami I tried change the define lines to undef .. but I didn't have any > luck doing that... > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 > From becker@scyld.com Fri Jun 14 19:44:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jun 14 18:44:01 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 In-Reply-To: <006701c2133b$bf0577c0$2224040a@hq.spinner.com> Message-ID: On Thu, 13 Jun 2002, G-man wrote: > This is a redhat 6.2 box running 2.2.19-6.2.16enterprise. Box is completely > up todate with its rpms.. > > kernel-enterprise-2.2.19-6.2.16 ... > I download the eepro100.c and pci-scan.c yesterday.. > I compiled modules like this: > gcc -I/usr/src/linux/include -I/usr/src/linux/include/linux/modversions.h -D > MODULE -D__KERNEL__ -DEXPORT_SYMTAB -O6 -c pci-scan.c Try using this Makefile ftp://www.scyld.com/pub/network/Makefile which tries to find the correct header files, despite the myriad ways that distributions try to misplace them. It should find the proper kernel header files, likely someplace such as -I/lib/modules/2.2.19-6.2.16/kernel/include/ > Using /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > __ioremap_R9eac042a Yup, wrong header files for the kernel you are using, combined with a module version implementation that's a little too picky. -- 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 naeem.m.afzal@intel.com Fri Jun 14 22:53:01 2002 From: naeem.m.afzal@intel.com (Afzal, Naeem M) Date: Fri Jun 14 21:53:01 2002 Subject: [eepro100] 82559ER eeprom Message-ID: <5D2136DF3DD5D311AE89009027C67FB0063EDFD1@fmsmsx96.fm.intel.com> What could be the reason for the driver to crash during init, when trying to write eeprom. Currently linux(2.4.17 rmk2) crashes while in do_eeprom_cmd() when it tries to write to eeprom. Any suggestion on this would be appreciated. thanks naeem ...... do_eeprom_cmd().... do { short dataval = (cmd & (1 << cmd_len)) ? EE_WRITE_1 : EE_WRITE_0; printk("go dataval\n"); io_outw(dataval, ee_addr); printk("go delay\n"); udelay(2); printk("go dataval EE_SHIFT\n"); io_outw(dataval | EE_SHIFT_CLK, ee_addr); printk("go delay\n"); udelay(2); retval = (retval << 1) | ((io_inw(ee_addr) & EE_DATA_READ) ? 1 : 0);<--- crashes } while (--cmd_len >= 0); Nic settings: Linux version 2.4.17-rmk2-adi (root@optimus) (gcc version 2.95.3) PCI Autoconfig: BAR 0, Mem, size=0x1000, address=0xfffff000 PCI Autoconfig: BAR 1, I/O, size=0x40, address=0xd9ffffc0 PCI Autoconfig: BAR 2, Mem, size=0x20000, address=0xfffc0000 ...... go init_etherdev done init_etherdev go read eeprom go EE_ENB, ee_addr=0xD9FFFFCE go delay go io_outw go delay go dataval go delay go dataval EE_SHIFT go delay Bad mode in data abort handler detected: mode IRQ_32 Vectors: Stubs: Internal error: Oops: 0 CPU: 0 pc : [] lr : [<400b4fc8>] Not tainted sp : 5ffadc40 ip : 5ffadc34 fp : 5ffadcb0 r10: 06000000 r9 : 4012aebc r8 : 4012ae98 r7 : 00000000 r6 : 0000001b r5 : d9ffffce r4 : 00004803 r3 : 4013f19c r2 : 00000000 r1 : 0000001a r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode IRQ_32 Segment kernel Control: 397F Table: 00004000 DAC: 0000001D Process swapper (pid: 1, stackpage=5ffad000) From christoph.plattner@alcatel.at Mon Jun 17 06:12:01 2002 From: christoph.plattner@alcatel.at (Christoph Plattner) Date: Mon Jun 17 05:12:01 2002 Subject: [eepro100] Short technical discussion about "No (RX) resources" Message-ID: <3D0DA7B4.5A87EB24@alcatel.at> Hello EEPRO100 hackers, hello Donald Becker, I want to discuss the reasons for the error messages No resources No RX resources I do not want to speak about versions of driver and if the driver is from the SCYLD donwloaded or if the driver comes from Linux. For discussing the problem with high-speed machines, I use to versions as examples: Linux-2.2.18 driver and thre current scyld driver of the eepro100.c. I ported a Linux-2.2.18 driver to our company own operating system (rail station and and rail controlling), and we found following situation: On machines up to PIII 500 (or more) no problems exist. On machines of PIII 700 sometimes the two error messages are seen, on fater machines (> 900MHz) this error message is always shown and the NIC is not working. This effect is complement to the "feelings" of a driver writer, as on a faster machine the refill of RX buffers is more propable and the "NO (RX) resources" should never occure. On slow machines the propability is higher, that a lack of resources may occure. On our system the number of skb buffers are fixed to 600 for 3 interfaces. Each interface has 64 RX buffers reserved, the STREAMS driver on top of it can hold at maximum 128 skbs, then it starts to drop. The test scenario only inlucde ONE interface, so this one interface can work with 472 skbs, of them are 64 reserverd for RX on it's own. There is definitively no resource problem getting skbs ! As seen in the mailing list, you often spoke from increasing the number of resources, but I think, this is not the problem here. Does the system loose interrupts on fast machines (so packets are not freed and the RX buffers are no refilled), or were there changes in done in the code to avoid this affect. Lets discuss some points in the code, which are seen as diffs between the 2.2.18 Linux drivers and the current down- loaded version of SCYLD. I only pointed out diffs, which are relevant for the problem described above, IMO: * In `wait_for_cmd_done()': This routine works in a different way. What was the rationale for changing this ? * Introductiuon of `do_slow_command()' * Chnaged code in `speedo_resume()' (this is only relevant for recovering the NIC after a TIMEOUT situation, is this correct ?). What was the rationale for changing this ? * Changed triggering in `speedo_start_xmit()': In older Linux code: The order is wait_for_cmd_done() clear_suspend() do CUResume spin_unlock_irqrestore() In current scyld code: clear_suspend() flow control for TX queues of linux kernel spin_unlock_irqrestore() wait_for_cmd_done() do CUResume What was the rationale for changing this ? * Additional handling of RXSuspend Interrupt Further keywords can be discussed: * Use of different FIFO threshold(s) * max interrupt work (200 at linux-2.2.18 and 20 @scyld) I hope you are interesting in such a short discussion having the technical view and pointing out, which the critical code is, having the problem on fast machines. BTW: I have the NDA with intel (in the company) and have the document for the EEPRO 100, so you can also point to chapters or refs. Christoph Plattner ------------------------------------------------------------------ private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at From j.radinger@phion.com Mon Jun 17 14:08:02 2002 From: j.radinger@phion.com (Joe Radinger) Date: Mon Jun 17 13:08:02 2002 Subject: [eepro100] should i be worried about my eepro cards In-Reply-To: References: Message-ID: <1024298169.32197.7.camel@yoda> --=-E2MvXSyTYtp3/5a7zrqN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-06-13 at 21:17, Donald Becker wrote:=20 > On 13 Jun 2002, Joe Radinger wrote: >=20 > > Subject: [eepro100] should i be worried about my eepro cards >=20 > Yes. >=20 > > 33Mhz pci + 66Mhz pci > > 4*dualport eepro100 cards (two on 33Mhz, two on 66Mhz) > > 1 onboard eepro100 > > > > eepro100.c:v1.17a 8/7/2001 Donald Becker > > http://www.scyld.com/network/eepro100.html > > divert: allocating divert_blk for eth0 >=20 > Presumably you are running a patched kernel to have the divert code... i took your netdrivers-package.=20 > > eth0: Intel PCI EtherExpress Pro100 at 0xa0042000, 00:09:6B:B0:21:55, > > Board assembly ffffff-255, Physical connectors present: RJ45 >=20 > This must be the on-board NIC? Usually that's at the end of bus 0 >=20 > > eth1: Intel PCI EtherExpress Pro100 at 0xa0044000, 00:02:B3:A9:A2:F9, > > Board assembly a56831-002, Physical connectors present: RJ45 > > eth2: Intel PCI EtherExpress Pro100 at 0xa0046000, 00:02:B3:A9:A2:FA, > > Board assembly a56831-002, Physical connectors present: RJ45 >=20 > One pair, good detection. >=20 > > eth3: Intel PCI EtherExpress Pro100 at 0xa0048000, 00:02:B3:A9:A5:E7, > > Board assembly a56831-002, Physical connectors present: RJ45 > > eth4: Intel PCI EtherExpress Pro100 at 0xa004a000, 00:02:B3:A9:A5:E8, > > Board assembly a56831-002, Physical connectors present: RJ45 >=20 > Same type of board >=20 > > eth5: Invalid EEPROM checksum 0x5773, check settings before activating > > this device! >=20 > Ohhh, bad news. >=20 > > eth5: Intel PCI EtherExpress Pro100 at 0xa004c000, FF:FF:B3:A9:FF:FF, >=20 > Bad station address. All other information is suspect. > Do not activate this device. >=20 > > Board assembly ffff31-002, Physical connectors present: RJ45 > > Primary interface chip unknown-15 PHY #31. >=20 > This will prevent the NIC from working correctly. >=20 > > eth6: Invalid EEPROM checksum 0x5673, check settings before activating > > this device! > > eth6: Intel PCI EtherExpress Pro100 at 0xa004e000, FF:FF:B3:A9:FF:FF, > > IRQ 15. > > eth7: Invalid EEPROM checksum 0x1d72, check settings before activating > > this device! > > eth7: Intel PCI EtherExpress Pro100 at 0xa0050000, FF:FF:B3:A9:FF:FF, > > eth8: Invalid EEPROM checksum 0x1c72, check settings before activating > > this device! > > eth8: Intel PCI EtherExpress Pro100 at 0xa0052000, FF:FF:B3:A9:FF:FF, >=20 > > attached is the output from eepro100-diag -a -e -m -f >=20 > Hmmm, the diag program didn't have a problem reading the EEPROM. >=20 > Which interfaces are on the 66Mhz bus? > I've tested the driver with a 66Mhz PCI bus, but there might be some > timing issue. Or this might just be a bus bridge issue. >=20 > Try compiling the driver with the additional flag > -DUSE_IO_OPS now i have a heavily patched kernel with netdrivers 3.1.1 AND the latest eepro100.c v1.23=20 note that this output came from an older driver. v1.17a=20 without -DUSE_IO_OPS, its the same, but -DUSE_IO_OPS solved my problem and arises an new one: lack of knowledge: what does this option mean? i tried the e100 driver from intel, seems to work, too.=20 thanks=20 josef --=-E2MvXSyTYtp3/5a7zrqN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9DYy4yOLl//lX6PMRAqceAKCGnQ2Yv2QwvEhSB3y2IaPuXdZG9wCg30kk RUJkJJcL38duLZ+LMFTRIIg= =faeb -----END PGP SIGNATURE----- --=-E2MvXSyTYtp3/5a7zrqN-- From johnsved@compuserve.com Mon Jun 17 14:10:04 2002 From: johnsved@compuserve.com (John Sved) Date: Mon Jun 17 13:10:04 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad Message-ID: <3D0DE121.7000608@compuserve.com> Hi, I have two Dell Inspiron 4000 connected to a home/office network. Several other PCs work OK with apparent 100/half. Dell no. 1 is more used. Dell no. 2 is on loan and used with a LAN for the first time. Dell no. 1 has a fancy intel windoze driver Dell no. 2 has a more basic intel windoze driver. Dell no. 2 works fine in 100/full with linux or the Win ME. Dell no. 1 works very poorly with windoze and linux. The Longshine LCS-883R-SW800M= switching Hub indicates that the Dell no. 1 is in full duplex but the link/Act LED is continuously flashing at about 1 Hz. This appears to be a problem with auto negotiation. I suspect that the Dell no. 1 windoze driver for the NIC has changed a register and it has not or cannot be changed by the eepro100. I can get it to change to 100/half in windoze but then the connection is poor. I have tried various options 0x10, 0x20, 0x100 and 0x200 and ether=0, 0, 0x200 eth0 etc. via the SuSE 8.0 YAST network card configuration tool. No change was observed. The ACT LED still flashes continuously and file transfers are flakey, network printing from Dell no. 1 fails. (The problem was also present with SuSE 7.2). The use of a different hub (Fibreline) "cures" the problem. But there are fewer indicator lamps to know the mode. (Side story: After exchanging a no-name hub that died three time in 10 weeks (3 hubs), I obtained an exchange for a Longshine Hub. This had a defective power supply unit which produced severe spikes that interferred with all NICs including Dell no. 2. The Distributor kindly exchanged the hub set. Talk about overlapping troubleshooting problems ......!) Is there something else to try ? (ie to make Dell no. 1 work as well as Dell no. 2.) Note: I have downloaded eepro100-diag, compiled it with gcc and tried to start it. Nothing happens. What is the correct procedure or command to invoke this tool, if it is needed ? Then what do I do to poke about in the registers and perhaps compare the Dell NICs ? Is there a "master reset" that would force the Dell no. 1 NIC chip to an "original" parameter set as with the Dell no. 2 ? - JS From becker@scyld.com Mon Jun 17 15:27:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jun 17 14:27:01 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad In-Reply-To: <3D0DE121.7000608@compuserve.com> Message-ID: On Mon, 17 Jun 2002, John Sved wrote: > I have two Dell Inspiron 4000 connected to a home/office network. > Several other PCs work OK with apparent 100/half. ... > Dell no. 1 works very poorly with windoze and linux. The Longshine > LCS-883R-SW800M= switching Hub indicates that the Dell no. 1 is in full > duplex but the link/Act LED is continuously flashing at about 1 Hz. .. > This appears to be a problem with auto negotiation. I suspect that the > Dell no. 1 windoze driver for the NIC has changed a register and it has > not or cannot be changed by the eepro100. I can get it to change to > 100/half in windoze but then the connection is poor. Something is broken. There should be no perceivable performance difference between half and full duplex. > I have tried various options 0x10, 0x20, 0x100 and 0x200 and ether=0, > 0, 0x200 eth0 etc. via the SuSE 8.0 YAST network card configuration > tool. Without knowing the SuSE configuration and driver version, it's difficult to advise you which options might be valid. > The use of a different hub (Fibreline) "cures" the problem. But there > are fewer indicator lamps to know the mode. That points to a hardware problem, or perhaps marginal cables. > Note: I have downloaded eepro100-diag, compiled it with gcc and tried to > start it. Nothing happens. What do you mean by "nothing happens"? Is there output? Try running 'mii-diag --watch'. -- 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 johnsved@compuserve.com Mon Jun 17 21:37:45 2002 From: johnsved@compuserve.com (John Sved) Date: Mon Jun 17 20:37:45 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad References: Message-ID: <3D0E65F6.90708@compuserve.com> Thanks for your comments. I have since noticed in the boot.msg log that DEll no. 1 has: <5>Intel(R) PRO/100 Fast Ethernet Adapter - Loadable driver, ver 1.8.37 <5>Copyright (c) 2002 Intel Corporation <5> <5>eth0: Intel(R) 8255x-based Ethernet Adapter <5> Mem:0xfbfff000 IRQ:11 Speed:100 Mbps Dx:Full <5> Hardware receive checksums enabled <5> cpu cycle saver enabled Repeated attempts to not have this in the SuSE YAST2 network card configuration have failed. i.e. it still appears. I think that it was the eepro100 driver at some earlier point. There is also some message on screen about tainting the kernel with an unnecessary driver. Dell no. 2 does not have any such entry in the boot.msg file. So this looks like a likely cause of the trouble. (Two drivers fighting ...) How can the e100 driver be removed ? -- JS Donald Becker wrote: > > On Mon, 17 Jun 2002, John Sved wrote: > > >>I have two Dell Inspiron 4000 connected to a home/office network. >>Several other PCs work OK with apparent 100/half. >> > ... > >>Dell no. 1 works very poorly with windoze and linux. The Longshine >>LCS-883R-SW800M= switching Hub indicates that the Dell no. 1 is in full >>duplex but the link/Act LED is continuously flashing at about 1 Hz. >> > .. > >>This appears to be a problem with auto negotiation. I suspect that the >>Dell no. 1 windoze driver for the NIC has changed a register and it has >>not or cannot be changed by the eepro100. I can get it to change to >>100/half in windoze but then the connection is poor. >> > > Something is broken. There should be no perceivable performance > difference between half and full duplex. > > >>I have tried various options 0x10, 0x20, 0x100 and 0x200 and ether=0, >>0, 0x200 eth0 etc. via the SuSE 8.0 YAST network card configuration >>tool. >> > > Without knowing the SuSE configuration and driver version, it's difficult to > advise you which options might be valid. > > >>The use of a different hub (Fibreline) "cures" the problem. But there >>are fewer indicator lamps to know the mode. >> > > That points to a hardware problem, or perhaps marginal cables. > > >>Note: I have downloaded eepro100-diag, compiled it with gcc and tried to >>start it. Nothing happens. >> > > What do you mean by "nothing happens"? Is there output? > > Try running 'mii-diag --watch'. > > > From becker@scyld.com Mon Jun 17 21:38:33 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jun 17 20:38:33 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad In-Reply-To: <3D0E65F6.90708@compuserve.com> Message-ID: On Tue, 18 Jun 2002, John Sved wrote: > I have since noticed in the boot.msg log that .. > Repeated attempts to not have this in the SuSE YAST2 network card > configuration have failed. i.e. it still appears. ... > There is also some message on screen about tainting the kernel with an > unnecessary driver. The Intel driver was not released under the GPL. Many (myself included) consider that a license violation -- the linux interface is necessarily a derivative work and must fall under the GPL. > How can the e100 driver be removed ? Delete the entry from /etc/modules.conf -- 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 bill@linuxcare.com Tue Jun 18 13:11:03 2002 From: bill@linuxcare.com (Bill Schoolcraft) Date: Tue Jun 18 12:11:03 2002 Subject: [eepro100] RedHat-6.2 and (IBM) Dual Port Server Adapter. Message-ID: <3D0F5025.6452F90A@linuxcare.com> Hello Family, I'm trying to see if there is any current information on the stability of the IBM "10/100 Dual Port Server Adapter", IBM part number 22P4901 We have reports of some latency problems and we upgraded to the Donald Becker 1.21 driver and we are getting some errors like the following: Command 0000 was not immediately accepted, 104 ticks! Command 0000 was not immediately accepted, 106 ticks! eth0: Unknown receiver error, status=0x7048. Command 0000 was not immediately accepted, 222 ticks! We are not too sure about the following syntax. /etc/conf.modules output: alias eth0 eepro100 alias eth1 eepro100 options eepro100 options=0x30,0x30,0x30 full_duplex=1,1,1 -- Bill Schoolcraft Linux/Unix System Engineer 650 Townsend Street San Francisco, CA 94103 SF (415) 354-4878 http://www.linuxcare.com "Levanto(tm), Your Mainframe Solution." From subscriptions@graphon.com Tue Jun 18 15:28:00 2002 From: subscriptions@graphon.com (Nate Amsden) Date: Tue Jun 18 14:28:00 2002 Subject: [eepro100] RedHat-6.2 and (IBM) Dual Port Server Adapter. References: <3D0F5025.6452F90A@linuxcare.com> Message-ID: <3D0F76D3.F779E111@graphon.com> Bill Schoolcraft wrote: > > Hello Family, > > I'm trying to see if there is any current information on the stability > of the IBM "10/100 Dual Port Server Adapter", IBM part number 22P4901 > > We have reports of some latency problems and we upgraded to the Donald > Becker 1.21 driver and we are getting some errors like the following: > > Command 0000 was not immediately accepted, 104 ticks! > Command 0000 was not immediately accepted, 106 ticks! > eth0: Unknown receiver error, status=0x7048. > Command 0000 was not immediately accepted, 222 ticks! while i have not tried this adapter, do these errors cause problems? I have 1 system that has a lot of: Command 0000 was not immediately accepted, 107 ticks! Command 0000 was not immediately accepted, 102 ticks! Command 0000 was not immediately accepted, 114 ticks! (about 4-5 a week, 145 total year to date) I haven't recieved the Unknown reciever error yet, at least since the beginning of the year(my syslog server keeps logs for 6 months) but from what I can tell it has no noticable impact on the system. running driver v1.17b on a Intel L440GX+ with onboard eepro100. its the only system on my networks that give the message .. nate -- Nate Amsden System Administrator GraphOn http://www.graphon.com From johnsved@compuserve.com Tue Jun 18 17:55:02 2002 From: johnsved@compuserve.com (John Sved) Date: Tue Jun 18 16:55:02 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad References: Message-ID: <3D0F89FB.5040002@compuserve.com> Donald Becker wrote: > > On Tue, 18 Jun 2002, John Sved wrote: > > >>>>How can the e100 driver be removed ? >>>> >>>Delete the entry from /etc/modules.conf >>> >>I removed all occurances in /etc/modules.conf, saved and restarted. >> >>The e100 entry in the boot.msg still appears. No change to the >>indicated NIC status on the hub. >> > > When does the e100 driver message appear ? > > Run 'lsmod'. The driver e100 driver should show up. lsmod shows e100 69272 Used 1 as the last item in the list. > If it doesn't, it might be built into the kernel. > > > > In modules.conf alias eth0 eepro100 appears at the end In /etc/sysconfig/kernel there was INITRD_MODULES="e100" I set this to INITRD_MODULES="" and rebooted this had no apparent effect the boot up on screen message ((from /var/boot.msg) still says <5>Intel(R) PRO/100 Fast Ethernet Adapter - Loadable driver, ver 1.8.37 <5>Copyright (c) 2002 Intel Corporation <5> <5>eth0: Intel(R) 8255x-based Ethernet Adapter <5> Mem:0xfbfff000 IRQ:11 Speed:100 Mbps Dx:Full <5> Hardware receive checksums enabled <5> cpu cycle saver enabled During the boot up the was also the message the e100 was loaded. From /var/log/messages Jun 17 12:18:51 john1 kernel: e100: eth0 NIC Link is Down Jun 17 12:18:55 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex Jun 17 12:22:52 john1 ifup: Configuration 'ppp0' has STARTMODE=manual: -> skipped Jun 17 12:22:52 john1 ifup: As we are called from rcnetwork we do not set it up, because Jun 17 12:22:52 john1 ifup: it was not set up manually or by hotplug before. Jun 17 12:23:02 john1 kernel: eth0: no IPv6 routers present Jun 17 12:25:13 john1 kernel: e100: eth0 NIC Link is Down Jun 17 12:25:19 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex Jun 17 12:25:44 john1 kdm[854]: pam_unix2: session finished for user root, service xdm Jun 17 14:17:10 john1 kernel: e100: eth0 NIC Link is Down Jun 17 14:17:12 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex Jun 17 14:17:14 john1 kernel: e100: eth0 NIC Link is Down Jun 17 14:17:18 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex Jun 17 14:17:24 john1 kernel: e100: eth0 NIC Link is Down Jun 17 14:17:28 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex Jun 17 14:19:39 john1 smpppd[1187]: smpppd version 0.73 started Jun 17 14:19:50 john1 ifup: Configuration 'ppp0' has STARTMODE=manual: -> skipped Jun 17 14:19:50 john1 ifup: As we are called from rcnetwork we do not set it up, because Jun 17 14:19:50 john1 ifup: it was not set up manually or by hotplug before. Jun 17 14:21:03 john1 ifup: Configuration 'ppp0' has STARTMODE=manual: -> skipped Jun 17 14:21:03 john1 ifup: As we are called from rcnetwork we do not set it up, because Jun 17 14:21:03 john1 ifup: it was not set up manually or by hotplug before. Jun 17 14:21:13 john1 kernel: eth0: no IPv6 routers present Jun 17 14:21:32 john1 kernel: e100: eth0 NIC Link is Down Jun 17 14:21:46 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex Jun 17 14:22:12 john1 kernel: e100: eth0 NIC Link is Down Jun 17 14:22:28 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex The UP DOWN messages appear frequently. Are they a cause of the Hub Link/Act LED flashing ? Is IRQ11 "overused" ? Dell No. 2 has eepro100 according to lsmod. the /var/log/messages shows that eepro100 v1.09 is used with eepro rev 1.36. a receiver lockup bug exists and -- enable work-around plus addition information First things first: how the heck do we get rid of replace e100 with eepro100 ? --JS From becker@scyld.com Tue Jun 18 17:55:39 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jun 18 16:55:39 2002 Subject: [eepro100] RedHat-6.2 and (IBM) Dual Port Server Adapter. In-Reply-To: <3D0F76D3.F779E111@graphon.com> Message-ID: On Tue, 18 Jun 2002, Nate Amsden wrote: > Bill Schoolcraft wrote: > > I'm trying to see if there is any current information on the stability > > of the IBM "10/100 Dual Port Server Adapter", IBM part number 22P4901 > > > > We have reports of some latency problems and we upgraded to the Donald > > Becker 1.21 driver and we are getting some errors like the following: > > > > Command 0000 was not immediately accepted, 104 ticks! > > Command 0000 was not immediately accepted, 106 ticks! I've updated the driver to wait longer before complaining, and to accurately report the command that was "stuck". This message is harmless if the driver continues running. > > eth0: Unknown receiver error, status=0x7048. This message is reporting "Rx has no resources", but it's not a lack of receive buffers. That likely means that the eepro100 chip couldn't get enough bus bandwidth, or there was a PCI transaction problem. > while i have not tried this adapter, do these errors cause problems? > I have 1 system that has a lot of: > Command 0000 was not immediately accepted, 107 ticks! > Command 0000 was not immediately accepted, 102 ticks! > Command 0000 was not immediately accepted, 114 ticks! Mostly harmless, although a properly working adapter in a system that's not overloaded should not take so long to do things. The cause of these messages seems to be very chip version specific. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue Jun 18 17:56:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jun 18 16:56:01 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad In-Reply-To: <3D0F89FB.5040002@compuserve.com> Message-ID: On Tue, 18 Jun 2002, John Sved wrote: > Donald Becker wrote: > > On Tue, 18 Jun 2002, John Sved wrote: > > > >>>>How can the e100 driver be removed ? > >>>> > >>>Delete the entry from /etc/modules.conf > >>> > >>I removed all occurances in /etc/modules.conf, saved and restarted. > >> > >>The e100 entry in the boot.msg still appears. No change to the > >>indicated NIC status on the hub. .. > > Run 'lsmod'. The driver e100 driver should show up. > shows e100 69272 Used 1 as the last item in the list. > In /etc/sysconfig/kernel > there was > INITRD_MODULES="e100" > I set this to > INITRD_MODULES="" Hmmm, I don't know what else loads modules.. anyone else have an idea? > Jun 17 12:18:51 john1 kernel: e100: eth0 NIC Link is Down > Jun 17 12:18:55 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex > Jun 17 12:25:13 john1 kernel: e100: eth0 NIC Link is Down > Jun 17 12:25:19 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex ... > The UP DOWN messages appear frequently. Are they a cause of the Hub > Link/Act LED flashing ? They are a symptom of a serious link problem. These messages are just a report, not a cause. > Is IRQ11 "overused" ? ...unrelated. The transceiver handles autonegotiation without needing the driver to deal with the timing. The IRQ shouldn't come into play The best diagnostic is eepro100-diag --watch or mii-diag --watch -- 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 gman@gman.infinex.com Tue Jun 18 21:35:01 2002 From: gman@gman.infinex.com (G-man) Date: Tue Jun 18 20:35:01 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 References: Message-ID: <001901c21728$f466be60$2224040a@hq.spinner.com> Makefile compiles pci-scan.c but not eepro100.c.. insmod/modprobeing the pci-scan.o still generates that error.. adding -D__module__enterprise makes everything good.. ----- Original Message ----- From: "Donald Becker" To: "G-man" Cc: Sent: Friday, June 14, 2002 3:43 PM Subject: Re: [eepro100] Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 > On Thu, 13 Jun 2002, G-man wrote: > > > This is a redhat 6.2 box running 2.2.19-6.2.16enterprise. Box is completely > > up todate with its rpms.. > > > > kernel-enterprise-2.2.19-6.2.16 > ... > > I download the eepro100.c and pci-scan.c yesterday.. > > I compiled modules like this: > > gcc -I/usr/src/linux/include -I/usr/src/linux/include/linux/modversions.h -D > > MODULE -D__KERNEL__ -DEXPORT_SYMTAB -O6 -c pci-scan.c > > Try using this Makefile > ftp://www.scyld.com/pub/network/Makefile > which tries to find the correct header files, despite the myriad ways > that distributions try to misplace them. > > It should find the proper kernel header files, likely someplace such as > -I/lib/modules/2.2.19-6.2.16/kernel/include/ > > > Using /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o > > /lib/modules/2.2.19-6.2.16enterprise/net/pci-scan.o: unresolved symbol > > __ioremap_R9eac042a > > Yup, wrong header files for the kernel you are using, combined with > a module version implementation that's a little too picky. > > -- > 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 > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 > From becker@scyld.com Wed Jun 19 10:59:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 19 09:59:01 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 In-Reply-To: <001901c21728$f466be60$2224040a@hq.spinner.com> Message-ID: On Tue, 18 Jun 2002, G-man wrote: > pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 > > Makefile compiles pci-scan.c but not eepro100.c.. insmod/modprobeing the > pci-scan.o still generates that error.. > > adding -D__module__enterprise makes everything good.. Sigh... OK, I need to figure out how to detect this in the Makefile. I don't have a copy of Red Hat's Enterprise server, so I can't find out myself. Does __module__enterprise show up in the include files in /lib/modules/2.2.19-6.2.16enterprise/kernel/include/ -- 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 robbie@microbus.com Wed Jun 19 11:29:04 2002 From: robbie@microbus.com (Robbie Dinn) Date: Wed Jun 19 10:29:04 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad Message-ID: Donald Becker wrote: >On Tue, 18 Jun 2002, John Sved wrote: >> Donald Becker wrote: >> > On Tue, 18 Jun 2002, John Sved wrote: >> > >> >>>>How can the e100 driver be removed ? >> >>>> >> >>>Delete the entry from /etc/modules.conf >> >>> >> >>I removed all occurances in /etc/modules.conf, saved and restarted. >> >> >> >>The e100 entry in the boot.msg still appears. No change to the >> >>indicated NIC status on the hub. >... >> > Run 'lsmod'. The driver e100 driver should show up. >> shows e100 69272 Used 1 as the last item in the list. > >> In /etc/sysconfig/kernel >> there was >> INITRD_MODULES="e100" >> I set this to >> INITRD_MODULES="" > >Hmmm, I don't know what else loads modules.. anyone else have an idea? This is SuSE 8.0 distribution, right? I use this too. Could it be that John Sved forgot to run the mk_initrd shell script? Note the underscore between the 'k' and 'i'. I think this recreates the /boot/initrd and /boot/initrd.suse ramdisk images based on what has been assigned to the INITRD_MODULES config value. I think you need to run lilo as well if the ramdisk images change. I make this mistake often. ---------- From: Donald Becker Sent: 18 June 2002 16:43 To: Robbie Dinn; john sved Cc: forum eepro100 Subject: Re: [eepro100] Twin laptops - one good NIC configuration - one bad On Tue, 18 Jun 2002, John Sved wrote: > Donald Becker wrote: > > On Tue, 18 Jun 2002, John Sved wrote: > > > >>>>How can the e100 driver be removed ? > >>>> > >>>Delete the entry from /etc/modules.conf > >>> > >>I removed all occurances in /etc/modules.conf, saved and restarted. > >> > >>The e100 entry in the boot.msg still appears. No change to the > >>indicated NIC status on the hub. .. > > Run 'lsmod'. The driver e100 driver should show up. > shows e100 69272 Used 1 as the last item in the list. > In /etc/sysconfig/kernel > there was > INITRD_MODULES="e100" > I set this to > INITRD_MODULES="" Hmmm, I don't know what else loads modules.. anyone else have an idea? > Jun 17 12:18:51 john1 kernel: e100: eth0 NIC Link is Down > Jun 17 12:18:55 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex > Jun 17 12:25:13 john1 kernel: e100: eth0 NIC Link is Down > Jun 17 12:25:19 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex ... > The UP DOWN messages appear frequently. Are they a cause of the Hub > Link/Act LED flashing ? They are a symptom of a serious link problem. These messages are just a report, not a cause. > Is IRQ11 "overused" ? ...unrelated. The transceiver handles autonegotiation without needing the driver to deal with the timing. The IRQ shouldn't come into play The best diagnostic is eepro100-diag --watch or mii-diag --watch -- 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 _______________________________________________ eepro100 mailing list eepro100@scyld.com http://www.scyld.com/mailman/listinfo/eepro100 <<< ==================== Original Email Header ==================== >>> Delivered-To: dial.pipex.com-microbus@dial.pipex.com Return-Path: X-Envelope-To: microbus@dial.pipex.com X-Envelope-From: eepro100-admin@scyld.com X-Delivery-Time: 1024433954 Received: (qmail 16722 invoked from network); 18 Jun 2002 20:59:14 -0000 Received: from gatun.mail.pipex.net (158.43.192.45) by firestorm.mail.pipex.net with SMTP; 18 Jun 2002 20:59:14 -0000 Received: (qmail 19598 invoked from network); 18 Jun 2002 20:59:42 -0000 Received: from hub.mail.gxn.net (195.147.246.56) by depot-6.dial.pipex.com with SMTP; 18 Jun 2002 20:59:42 -0000 Received: from dsl093-058-083.blt1.dsl.speakeasy.net ([66.93.58.83] helo=blueraja.scyld.com) by hub.mail.gxn.net with esmtp (Exim 3.34 #3) id 17KQ3W-00029T-00 for robbie@microbus.co.uk; Tue, 18 Jun 2002 21:58:26 +0100 Received: from dsl093-058-083.blt1.dsl.speakeasy.net (localhost.localdomain [127.0.0.1]) by blueraja.scyld.com (8.11.6/8.11.6) with ESMTP id g5IKu4O24412; Tue, 18 Jun 2002 16:56:04 -0400 Received: from localhost.localdomain (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by blueraja.scyld.com (8.11.6/8.11.6) with ESMTP id g5IKhGO23996 for ; Tue, 18 Jun 2002 16:43:16 -0400 Received: from localhost (becker@localhost) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id QAA06363; Tue, 18 Jun 2002 16:43:08 -0400 From: Donald Becker X-X-Sender: To: John Sved cc: forum eepro100 Subject: Re: [eepro100] Twin laptops - one good NIC configuration - one bad In-Reply-To: <3D0F89FB.5040002@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eepro100-admin@scyld.com Errors-To: eepro100-admin@scyld.com X-BeenThere: eepro100@scyld.com X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Linux driver development for the Intel PCI/CardBus EEPro 100 List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 18 Jun 2002 16:43:08 -0400 (EDT) Date: Tue, 18 Jun 2002 16:43:08 -0400 (EDT) ---------- robbie@microbus.co.uk From johnsved@compuserve.com Wed Jun 19 15:10:12 2002 From: johnsved@compuserve.com (John Sved) Date: Wed Jun 19 14:10:12 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad References: Message-ID: <3D10B72B.4070602@compuserve.com> Problem Reminder: As soon as the box is powered the Hub shows the link/ACT (Traffic) lamp to be flashing at ~ 1 Hz. The NIC chip works but very poorly. A direct laptop top laptop test shows acceptably high data transfer rates. The NIC works better with a different Hub but still not correctly. I have emailed DELL's help desk with a trouble shooting report to get their opinion (i.e. is it failed hardware, failed firmware or what ?) Perhaps the info below will tell those who can understand it and suggest a "register fix". >>Jun 17 12:25:13 john1 kernel: e100: eth0 NIC Link is Down >>Jun 17 12:25:19 john1 kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex >> > ... > >>The UP DOWN messages appear frequently. Are they a cause of the Hub >>Link/Act LED flashing ? >> > > They are a symptom of a serious link problem. These messages are just a > report, not a cause. > Robbie Dinn wrote: > > Donald Becker wrote: > >>On Tue, 18 Jun 2002, John Sved wrote: >> >>>Donald Becker wrote: >>> > On Tue, 18 Jun 2002, John Sved wrote: >>> > >>> >>>>How can the e100 driver be removed ? >>> >>>> >>> >>>Delete the entry from /etc/modules.conf >>> >>> >>> >>I removed all occurances in /etc/modules.conf, saved and restarted. >>> >> >>> >>The e100 entry in the boot.msg still appears. No change to the >>> >>indicated NIC status on the hub. >>> > > This is SuSE 8.0 distribution, right? Yes. > I use this too. > > Could it be that John Sved forgot to run the mk_initrd shell > script? Note the underscore between the 'k' and 'i'. First I tried to read about this: The SuSe help about compiling kernels and mkinitrd just confused. In the end I tried the mk_initrd. No error reported but no indication that it worked. After trying to find any changed file in /boot , I rebooted. It worked ! The e100 message was gone. No eepro100 message during boot. But lsmod reports eepro100. Thanks Robbie Dinn. After copying the compiled eepro100-diag to /usr/bin I got the following: xxxxx:~ # eepro100-diag -a -f eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xdcc0. i82557 chip registers at 0xdcc0: 0c000050 02e02000 00000000 00080002 182545e1 00000600 No interrupt sources are pending. The transmit unit state is 'Suspended'. The receive unit state is 'Ready'. This status is normal for an activated but idle interface. The Command register has an unprocessed command 0c00(?!). xxxxx:~ # eepro100-diag -e -f eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xdcc0. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:20:E0:6B:FC:BC. Receiver lock-up bug exists. (The driver work-around *is* implemented.) Board assembly 727095-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Sleep mode is enabled. This is not recommended. Under high load the card may not respond to PCI requests, and thus cause a master abort. To clear sleep mode use the '-G 0 -w -w -f' options. xxxxx:~ # eepro100-diag -m -f eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xdcc0. MII PHY #1 transceiver registers: 1000 782d 02a8 0154 05e1 45e1 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 0203 0000 0001 1f18 0000 0001 2b43 0001 0000 0000 3000 0000 0000 0000 0000 0000. xxxxx:~ # Please suggest the next trouble shooting steps. -- JS From becker@scyld.com Wed Jun 19 15:17:03 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 19 14:17:03 2002 Subject: [eepro100] Twin laptops - one good NIC configuration - one bad In-Reply-To: <3D10B72B.4070602@compuserve.com> Message-ID: On Wed, 19 Jun 2002, John Sved wrote: > As soon as the box is powered the Hub shows the link/ACT (Traffic) lamp > to be flashing at ~ 1 Hz. The NIC chip works but very poorly. A > direct laptop top laptop test shows acceptably high data transfer rates. > The NIC works better with a different Hub but still not correctly. What cable are you using? This can happen if the cable is not paired properly -- the link works during autonegotation at 10Mbps, but fails with 100Mbps. > After copying the compiled eepro100-diag to /usr/bin I got the following: ... > xxxxx:~ # eepro100-diag -e -f > eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xdcc0. ... > Primary interface chip i82555 PHY #1. > Sleep mode is enabled. This is not recommended. > Under high load the card may not respond to > PCI requests, and thus cause a master abort. > To clear sleep mode use the '-G 0 -w -w -f' options. This misconfiguration should be corrected (it's an Intel bug), but this is not your problem. > xxxxx:~ # eepro100-diag -m -f > MII PHY #1 transceiver registers: > 1000 782d 02a8 0154 05e1 45e1 0003 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 0203 0000 0001 1f18 0000 0001 2b43 0001 > 0000 0000 3000 0000 0000 0000 0000 0000. > Please suggest the next trouble shooting steps. Run 'mii-diag --watch'. -- 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 gman@gman.infinex.com Thu Jun 20 16:41:01 2002 From: gman@gman.infinex.com (G-man) Date: Thu Jun 20 15:41:01 2002 Subject: [eepro100] Unresolved symbols, pci-scan.c/eepro100.c and 2.2.19-6.2.16enterprise redhat 6.2 References: Message-ID: <003301c21892$15291160$2224040a@hq.spinner.com> > > Sigh... > > OK, I need to figure out how to detect this in the Makefile. I don't > have a copy of Red Hat's Enterprise server, so I can't find out myself. > > Does __module__enterprise show up in the include files in > /lib/modules/2.2.19-6.2.16enterprise/kernel/include/ > only thing I could find that had __module__enterprise was autoconf.h.. But from that, it only looks like it trying to define BIGMEM for the bigmem patch.. From gman@gman.infinex.com Thu Jun 20 17:11:00 2002 From: gman@gman.infinex.com (G-man) Date: Thu Jun 20 16:11:00 2002 Subject: [eepro100] Command 0000 was not immediately accepted, BLAH ticks??.. Message-ID: <004101c21896$a8cc0860$2224040a@hq.spinner.com> on a compaq dl360 w/ 2 1ghz cpus running rehat 6.2 with 2.2.19-6.2.16enterprise kernel eepro100 v1.23 6/5/2002 We have the card and switch running force at 100 FD w/ mii-tool.... I've gotten the following message/warning/error(?): Command 0000 was not immediately accepted, 141 ticks! Command 0000 was not immediately accepted, 132 ticks! Command 0000 was not immediately accepted, 102 ticks! Command 0000 was not immediately accepted, 106 ticks! Command 0000 was not immediately accepted, 106 ticks! Command 0000 was not immediately accepted, 152 ticks! Just wanted to find out what this was and what happens when this orrurs.. thanks.. From amitk@ittc.ku.edu Fri Jun 21 03:21:01 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Fri Jun 21 02:21:01 2002 Subject: [eepro100] eepro100 in 10Mbit mode Message-ID: Hi, I am trying to create a network where in the edges are 100Mbit and the core is a throttled 10Mbit as follows: | | 100Mbit | core | 100Mbit |*******| <-------->| |*******| | <-------> |*******| switch | switch | switch | / | \ | | / | \ | | R1 R2 R3| | | |-- edge ------|--------- core -------------|--- edge ------| R1, R2 and R3 are 3 routers containing eepro100 cards connected to a Netgear FS105 100Mbit core switch. I would like to throttle these interfaces to 10Mbits so that the effective throughput of the network becomes 10Mbit and _queuing_ occurs. But on using mii-tool to force these interfaces to 10baseT-FD, there are _many_ collisions on the core switch which kills even a 5Mbit flow to 3Mbit. I have tried 10baseT-HD too, but the collisions still seem to occur. Is there something fundamentally flawed in this design? TIA. ciao, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From becker@scyld.com Fri Jun 21 11:39:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jun 21 10:39:01 2002 Subject: [eepro100] eepro100 in 10Mbit mode In-Reply-To: Message-ID: On Fri, 21 Jun 2002, Amit Kucheria wrote: > I am trying to create a network where in the edges are 100Mbit and the > core is a throttled 10Mbit as follows: > | | > 100Mbit | core | 100Mbit > |*******| <-------->| |*******| | <-------> |*******| > switch | switch | switch > | / | \ | > | / | \ | > | R1 R2 R3| > | | > |-- edge ------|--------- core -------------|--- edge ------| > > R1, R2 and R3 are 3 routers containing eepro100 cards connected to a > Netgear FS105 100Mbit core switch. I would like to throttle these > interfaces to 10Mbits so that the effective throughput of the network > becomes 10Mbit and _queuing_ occurs. > > But on using mii-tool to force these interfaces to 10baseT-FD, there are > _many_ collisions on the core switch which kills even a 5Mbit flow to > 3Mbit. I have tried 10baseT-HD too, but the collisions still seem to > occur. Is there something fundamentally flawed in this design? You are forcing the interface to full duplex? Unless you link partner is also forced to full duplex, you will encounter network errors and serious performance problems. I never recommend forced full duplex. If you don't have autonegotiation on an Ethernet link, use standard Ethernet (CSMA/CD, "half duplex"). If you want to limit the negotiated speed, use the '-A' option to the mii-diag program to limit the advertised capabilities: http://www.scyld.com/diag/index.html -- 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 johnsved@compuserve.com Fri Jun 21 11:54:02 2002 From: johnsved@compuserve.com (John Sved) Date: Fri Jun 21 10:54:02 2002 Subject: [Fwd: Re: [eepro100] Twin laptops - one good NIC configuration - one bad] Message-ID: <3D1233A0.6030404@compuserve.com> -------- Original Message -------- Subject: Re: [eepro100] Twin laptops - one good NIC configuration - one bad Date: Thu, 20 Jun 2002 17:48:32 +0200 From: John Sved Organization: NSD limited To: Donald Becker References: Last chapter ..... I called Dell this morning. I was told to swap the Action Tec NIC + 56 K modem Combo internal card. This moved the problem from Dell No. 1 to Dell No. 2. I also tried every patch cable that I have just to be sure. The conclusion is that the NIC chip is indeed very marginal. Although Dell state that they normally refer customers to the third party suppliers in cases such as NICs and they only support custumers to get NICs going but not to performance tune them, Dell will, in this case (with so much trouble shooting effort) replace it within a day. They will come to me with a replacement module ! That must be in the service contract !! Thanks for your help Donald. -- JS Donald Becker wrote: > > On Wed, 19 Jun 2002, John Sved wrote: > > >> > What cable are you using? This can happen if the cable is not paired >> > properly -- the link works during autonegotation at 10Mbps, but fails >> > with 100Mbps. >> >>I am using various CAT 5 patch cables rated for 100Mhz. I have tried >>the usual cable swaps. >> > > Then you have a hardware problem. > > >>XXXX:~ # mii-diag --watch >>Using the default interface 'eth0'. >>Basic registers of MII PHY #1: 1000 782d 02a8 0154 05e1 45e1 0001 0000. >> > ... > >>I pulled out the cable, reinserted it and swapped with the patch cable >>on the no. 2 Dell (healthy one) as you can see below. >> >>Monitoring the MII transceiver status. >>21:03:52.824 Baseline value of MII BMSR (basic mode status register) is >>782d. >>21:03:56.327 MII BMSR now 7809: no link, NWay busy, No Jabber (0000). >> > > Link failure. > >>21:03:59.837 MII BMSR now 7829: no link, NWay done, No Jabber (45e1). >> New link partner capability is 45e1 0003: 10/100 switch w/ flow >>control. >> > > Finished autonegotiation. > > >>21:03:59.847 MII BMSR now 782d: Good link, NWay done, No Jabber (45e1). >>21:04:02.357 MII BMSR now 7809: no link, NWay busy, No Jabber (0000). >> > > Link failure after 2.5 seconds. The transceiver expects to see > 100baseTx link beat within one second after negotiation. This is at the > upper end of the limit that the transceiver should wait. > Autonegotiation can take up to 3 seconds. > > >>21:04:21.467 MII BMSR now 782d: Good link, NWay done, No Jabber (45e1). >> New link partner capability is 45e1 0003: 10/100 switch w/ flow >>control. >> > > Presumably this is the cable swap? > > >>21:04:25.177 MII BMSR now 7809: no link, NWay busy, No Jabber (0000). >>21:04:31.287 MII BMSR now 7829: no link, NWay done, No Jabber (45e1). >> New link partner capability is 45e1 0003: 10/100 switch w/ flow >>control. >>21:04:31.297 MII BMSR now 782d: Good link, NWay done, No Jabber (45e1). >>21:04:34.207 MII BMSR now 7809: no link, NWay busy, No Jabber (0000). >> > > Yup, you have a link stability problem. It really looks like hardware. > > From amitk@ittc.ku.edu Fri Jun 21 16:20:01 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Fri Jun 21 15:20:01 2002 Subject: [eepro100] eepro100 in 10Mbit mode In-Reply-To: Message-ID: On Fri, 21 Jun 2002, Donald Becker wrote: > > But on using mii-tool to force these interfaces to 10baseT-FD, there are > > _many_ collisions on the core switch which kills even a 5Mbit flow to > > 3Mbit. I have tried 10baseT-HD too, but the collisions still seem to > > occur. Is there something fundamentally flawed in this design? > > You are forcing the interface to full duplex? > Unless you link partner is also forced to full duplex, you will > encounter network errors and serious performance problems. > > I never recommend forced full duplex. If you don't have autonegotiation > on an Ethernet link, use standard Ethernet (CSMA/CD, "half duplex"). > > If you want to limit the negotiated speed, use the '-A' option to the > mii-diag program to limit the advertised capabilities: > http://www.scyld.com/diag/index.html > That worked! Using 'mii-tool -A 10baseT' works. This seems to do sane autonegotiation with the switch. Thanks. -Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From mjbarnes@cisco.com Fri Jun 21 18:04:02 2002 From: mjbarnes@cisco.com (Michael Barnes) Date: Fri Jun 21 17:04:02 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 Message-ID: <3D139488.4C734B22@cisco.com> I just got an IBM T23, installed RedHat 7.3, and did up2date. Everything is working pretty well, except that if I try to do too much at once, I get this: Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! Jun 21 13:56:54 dhcp-2545-22 last message repeated 10 times Jun 21 13:57:55 dhcp-2545-22 last message repeated 32 times Jun 21 13:58:25 dhcp-2545-22 last message repeated 15 times Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 0c80 at 30928/30988 command 200c0000. I saw in the archive a message that suggests to disable sleep mode, but I can't find instructions on how to do that, if that would help. Can anyone help? Thanks Michael From mjbarnes@cisco.com Fri Jun 21 18:16:01 2002 From: mjbarnes@cisco.com (Michael Barnes) Date: Fri Jun 21 17:16:01 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 Message-ID: <3D13974D.C17C7C5B@cisco.com> I just got an IBM T23, installed RedHat 7.3, and did up2date, and installed the vpn client v3.5.2. Everything is working pretty well, except that if I try to do too much at once, I get this: Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! Jun 21 13:56:54 dhcp-2545-22 last message repeated 10 times Jun 21 13:57:55 dhcp-2545-22 last message repeated 32 times Jun 21 13:58:25 dhcp-2545-22 last message repeated 15 times Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 0c80 at 30928/30988 command 200c0000. It does seem to work fine when I'm at the office, but maybe I haven't stressed it as much from the office. Can anyone help? Thanks Michael From becker@scyld.com Fri Jun 21 22:21:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jun 21 21:21:01 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 In-Reply-To: <3D139488.4C734B22@cisco.com> Message-ID: On Fri, 21 Jun 2002, Michael Barnes wrote: > I just got an IBM T23, installed RedHat 7.3, and did up2date. .. > Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! .. > Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed > out > Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 > 0c80 at 30928/30988 command 200c0000. > > I saw in the archive a message that suggests to disable sleep mode, but I > can't find instructions on how to do that, if that would help. Run eepro100-diag -ee http://www.scyld.com/diag/index.html -- 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 mjbarnes@cisco.com Sat Jun 22 02:08:01 2002 From: mjbarnes@cisco.com (Michael Barnes) Date: Sat Jun 22 01:08:01 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 References: Message-ID: <3D140613.B0C524AE@cisco.com> Thanks! Does this just need to be run once, or does it need to be put in the startup script? Donald Becker wrote: > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > I just got an IBM T23, installed RedHat 7.3, and did up2date. > .. > > Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! > .. > > Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed > > out > > Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 > > 0c80 at 30928/30988 command 200c0000. > > > > I saw in the archive a message that suggests to disable sleep mode, but I > > can't find instructions on how to do that, if that would help. > > Run > eepro100-diag -ee > > http://www.scyld.com/diag/index.html > > -- > 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 > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 -- Michael Barnes Core IP Eng - Routing 408-525-2785 From mjbarnes@cisco.com Sat Jun 22 02:29:01 2002 From: mjbarnes@cisco.com (Michael Barnes) Date: Sat Jun 22 01:29:01 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 References: Message-ID: <3D140AE6.8885630B@cisco.com> Donald Becker wrote: > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > I just got an IBM T23, installed RedHat 7.3, and did up2date. > .. > > Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! > .. > > Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed > > out > > Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 > > 0c80 at 30928/30988 command 200c0000. > > > > I saw in the archive a message that suggests to disable sleep mode, but I > > can't find instructions on how to do that, if that would help. > > Run > eepro100-diag -ee > > http://www.scyld.com/diag/index.html I am getting the same errors even after using that command. What else could be the cause? > -- > 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 > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 -- Michael Barnes Core IP Eng - Routing 408-525-2785 From becker@scyld.com Sat Jun 22 02:42:00 2002 From: becker@scyld.com (Donald Becker) Date: Sat Jun 22 01:42:00 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 In-Reply-To: <3D140AE6.8885630B@cisco.com> Message-ID: On Fri, 21 Jun 2002, Michael Barnes wrote: > Donald Becker wrote: > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > I just got an IBM T23, installed RedHat 7.3, and did up2date. > > > Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! > > .. > > > Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed > > > out > > > Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 > > > 0c80 at 30928/30988 command 200c0000. ... > > > I saw in the archive a message that suggests to disable sleep mode, but I > > > can't find instructions on how to do that, if that would help. > > Run > > eepro100-diag -ee > I am getting the same errors even after using that command. What else could > be the cause? What did the command report? What driver version are you using? -- 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 mjbarnes@cisco.com Sat Jun 22 03:29:00 2002 From: mjbarnes@cisco.com (Michael Barnes) Date: Sat Jun 22 02:29:00 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 References: Message-ID: <3D141916.57CB72A9@cisco.com> Donald Becker wrote: > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > Donald Becker wrote: > > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > > I just got an IBM T23, installed RedHat 7.3, and did up2date. > > > > Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! > > > .. > > > > Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed > > > > out > > > > Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 > > > > 0c80 at 30928/30988 command 200c0000. > ... > > > > I saw in the archive a message that suggests to disable sleep mode, but I > > > > can't find instructions on how to do that, if that would help. > > > Run > > > eepro100-diag -ee > > > I am getting the same errors even after using that command. What else could > > be the cause? > > What did the command report? This is the console log from when I checked the interface, disabled sleep mode, and re-checked the interface [root@localhost eepro100-diag]# ./eepro100-diag -ee -f eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel Pro/100 VE (type 1031) adapter at 0x6400. EEPROM contents, size 64x16: 00: d000 bf59 b1ec 1a03 0000 0201 4701 0000 0x08: 0000 0000 49a2 0209 1014 007f 0000 0000 ... 0x20: 0000 0000 0000 1031 0000 0000 0000 0000 ... 0x30: 002c 4000 4016 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 4030 0000 0000 0000 e98f The EEPROM checksum is correct. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:D0:59:BF:EC:B1. Board assembly 000000-000, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Sleep mode is enabled. This is not recommended. Under high load the card may not respond to PCI requests, and thus cause a master abort. To clear sleep mode use the '-G 0 -w -w -f' options. [root@localhost eepro100-diag]# ./eepro100-diag -G 0 -w -w -f eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel Pro/100 VE (type 1031) adapter at 0x6400. Writing 49a0 to configuration word 10. 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. [root@localhost eepro100-diag]# [root@localhost eepro100-diag]# [root@localhost eepro100-diag]# ./eepro100-diag -ee eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel Pro/100 VE (type 1031) adapter at 0x6400. A potential i82557 chip has been found, but it appears to be active. Either shutdown the network, or use the '-f' flag. [root@localhost eepro100-diag]# ./eepro100-diag -ee -f eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel Pro/100 VE (type 1031) adapter at 0x6400. EEPROM contents, size 64x16: 00: d000 bf59 b1ec 1a03 0000 0201 4701 0000 0x08: 0000 0000 49a0 0209 1014 007f 0000 0000 ... 0x20: 0000 0000 0000 1031 0000 0000 0000 0000 ... 0x30: 002c 4000 4016 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 4030 0000 0000 0000 e991 The EEPROM checksum is correct. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:D0:59:BF:EC:B1. Board assembly 000000-000, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. > What driver version are you using? It looks like it is v1.09 Revision 1.36 > -- > 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 -- Michael Barnes Core IP Eng - Routing 408-525-2785 From becker@scyld.com Sat Jun 22 09:24:01 2002 From: becker@scyld.com (Donald Becker) Date: Sat Jun 22 08:24:01 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 In-Reply-To: <3D141916.57CB72A9@cisco.com> Message-ID: On Fri, 21 Jun 2002, Michael Barnes wrote: > Donald Becker wrote: > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > Donald Becker wrote: > > > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > > > I just got an IBM T23, installed RedHat 7.3, and did up2date. > > > > > Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! > > > > .. > > > > > Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed > > > > > out > > > > > Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 > > > > > 0c80 at 30928/30988 command 200c0000. > > ... > > > > > I saw in the archive a message that suggests to disable sleep mode, but I > > > > > can't find instructions on how to do that, if that would help. > > > > Run > > > > eepro100-diag -ee ... > Sleep mode is enabled. This is not recommended. > Under high load the card may not respond to > PCI requests, and thus cause a master abort. > To clear sleep mode use the '-G 0 -w -w -f' options. ... > [root@localhost eepro100-diag]# ./eepro100-diag -G 0 -w -w -f > eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) > Writing 49a0 to configuration word 10. OK, that clears the sleep mode bit, which causes PCI protocol errors. You must cold power cycle the machine for this to take effect. (There is no way for the driver to clear the bit during operation, or the EEPROM-setting step wouldn't be needed.) > > What driver version are you using? > > It looks like it is v1.09 Revision 1.36 The Sleep Mode bit was definitely one problem If cold booting didn't solve the other problems, blame the last person to modify the driver... -- 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 mjbarnes@cisco.com Sat Jun 22 14:21:02 2002 From: mjbarnes@cisco.com (Michael Barnes) Date: Sat Jun 22 13:21:02 2002 Subject: [eepro100] RedHat 7.3 & vpn client 3.5.2 on T23 References: Message-ID: <3D14B1BD.F1BC73FC@cisco.com> Donald Becker wrote: > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > Donald Becker wrote: > > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > > Donald Becker wrote: > > > > > On Fri, 21 Jun 2002, Michael Barnes wrote: > > > > > > I just got an IBM T23, installed RedHat 7.3, and did up2date. > > > > > > Jun 21 13:56:23 dhcp-2545-22 kernel: eepro100: wait_for_cmd_done timeout! > > > > > .. > > > > > > Jun 21 13:58:27 dhcp-2545-22 kernel: NETDEV WATCHDOG: eth0: transmit timed > > > > > > out > > > > > > Jun 21 13:58:27 dhcp-2545-22 kernel: eth0: Transmit timed out: status 0050 > > > > > > 0c80 at 30928/30988 command 200c0000. > > > ... > > > > > > I saw in the archive a message that suggests to disable sleep mode, but I > > > > > > can't find instructions on how to do that, if that would help. > > > > > Run > > > > > eepro100-diag -ee > ... > > Sleep mode is enabled. This is not recommended. > > Under high load the card may not respond to > > PCI requests, and thus cause a master abort. > > To clear sleep mode use the '-G 0 -w -w -f' options. > ... > > [root@localhost eepro100-diag]# ./eepro100-diag -G 0 -w -w -f > > eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) > > Writing 49a0 to configuration word 10. > > OK, that clears the sleep mode bit, which causes PCI protocol errors. > You must cold power cycle the machine for this to take effect. (There > is no way for the driver to clear the bit during operation, or the > EEPROM-setting step wouldn't be needed.) Okay, I was lazy and didn't do the cold power cycle before. After that it does seem to be working just fine. Thank you! > > -- > 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 -- Michael Barnes Core IP Eng - Routing 408-525-2785 From naeem.m.afzal@intel.com Mon Jun 24 13:47:04 2002 From: naeem.m.afzal@intel.com (Afzal, Naeem M) Date: Mon Jun 24 12:47:04 2002 Subject: [eepro100] WATCHDOG timeout Message-ID: <5D2136DF3DD5D311AE89009027C67FB0063EDFEC@fmsmsx96.fm.intel.com> Hi, I am getting this watchdog timeout on 2.4.17 kernel. Root filesystem is mounted over NFS. NIC just stops responding frequently. I already checked eeprom setting and the sleep mode is not set. Could you give me some clue on how I can debug this issue. thanks naeem root@10.3.19.183:~# ping 10.3.19.158 PING 10.3.19.158 (10.3.19.158): 56 data bytes 64 bytes from 10.3.19.158: icmp_seq=0 ttl=255 time=0.2 ms 64 bytes from 10.3.19.158: icmp_seq=1 ttl=255 time=0.2 ms 64 bytes from 10.3.19.158: icmp_seq=2 ttl=255 time=0.1 ms 64 bytes from 10.3.19.158: icmp_seq=3 ttl=255 time=0.2 ms 64 bytes from 10.3.19.158: icmp_seq=4 ttl=255 time=0.1 ms 64 bytes from 10.3.19.158: icmp_seq=5 ttl=255 time=0.1 ms 64 bytes from 10.3.19.158: icmp_seq=6 ttl=255 time=0.1 ms 64 bytes from 10.3.19.158: icmp_seq=7 ttl=255 time=0.1 ms <5>nfs: server 10.3.19.158 not responding, still trying <5>nfs: server 10.3.19.158 not responding, still trying <6>NETDEV WATCHDOG: eth0: transmit timed out <4>eth0: Transmit timed out: status f048 0c00 at 2490/2518 command 000ca000. <7>eth0: Printing Rx ring (next to receive into 4421, dirty index 4421). <7>eth0: 0 0000a022. <7>eth0: 1 0000a022. <7>eth0: 2 0000a022. <7>eth0: 3 0000a020. <7>eth0: l 4 c000a020. <7>eth0: *= 5 0000a020. <7>eth0: 6 0000a020. <7>eth0: 7 0000a022. <7>eth0: 8 0000a022. <7>eth0: 9 0000a020. <7>eth0: 10 0000a022. <7>eth0: 11 0000a022. <7>eth0: 12 0000a020. <7>eth0: 13 0000a022. <7>eth0: 14 0000a022. <7>eth0: 15 0000a020. <7>eth0: 16 0000a022. <7>eth0: 17 0000a022. <7>eth0: 18 0000a022. <7>eth0: 19 0000a022. <7>eth0: 20 0000a022. <7>eth0: 21 0000a022. <7>eth0: 22 0000a022. <7>eth0: 23 0000a022. <7>eth0: 24 0000a022. <7>eth0: 25 0000a022. <7>eth0: 26 0000a022. <7>eth0: 27 0000a020. <7>eth0: 28 0000a022. <7>eth0: 29 0000a022. <7>eth0: 30 0000a022. <7>eth0: 31 0000a022. <6>NETDEV WATCHDOG: eth0: transmit timed out <4>eth0: Transmit timed out: status f048 0c00 at 2518/2546 command 0001a000. <7>eth0: Printing Rx ring (next to receive into 4421, dirty index 4421). <7>eth0: 0 0000a022. <7>eth0: 1 0000a020. <7>eth0: 2 0000a020. <7>eth0: 3 0000a022. <7>eth0: l 4 c000a020. <7>eth0: *= 5 0000a022. <7>eth0: 6 0000a020. <7>eth0: 7 0000a022. <7>eth0: 8 0000a022. <7>eth0: 9 0000a020. <7>eth0: 10 0000a020. <7>eth0: 11 0000a020. <7>eth0: 12 0000a022. <7>eth0: 13 0000a022. <7>eth0: 14 0000a022. <7>eth0: 15 0000a022. <7>eth0: 16 0000a020. <7>eth0: 17 0000a022. <7>eth0: 18 0000a022. <7>eth0: 19 0000a022. <7>eth0: 20 0000a020. <7>eth0: 21 0000a022. <7>eth0: 22 0000a022. <7>eth0: 23 0000a020. <7>eth0: 24 0000a022. <7>eth0: 25 0000a022. <7>eth0: 26 0000a022. <7>eth0: 27 0000a022. <7>eth0: 28 0000a020. <7>eth0: 29 0000a022. <7>eth0: 30 0000a022. <7>eth0: 31 0000a020. <6>NETDEV WATCHDOG: eth0: transmit timed out <4>eth0: Transmit timed out: status f048 0c00 at 2546/2574 command 0001a000. <7>eth0: Printing Rx ring (next to receive into 4421, dirty index 4421). <7>eth0: 0 0000a020. <7>eth0: 1 0000a020. <7>eth0: 2 0000a022. <7>eth0: 3 0000a022. <7>eth0: l 4 c000a022. <7>eth0: *= 5 0000a022. <7>eth0: 6 0000a022. <7>eth0: 7 0000a022. <7>eth0: 8 0000a022. <7>eth0: 9 0000a022. <7>eth0: 10 0000a022. <7>eth0: 11 0000a022. <7>eth0: 12 0000a022. <7>eth0: 13 0000a022. <7>eth0: 14 0000a022. <7>eth0: 15 0000a022. <7>eth0: 16 0000a020. <7>eth0: 17 0000a020. <7>eth0: 18 0000a022. <7>eth0: 19 0000a022. <7>eth0: 20 0000a022. <7>eth0: 21 0000a022. <7>eth0: 22 0000a020. <7>eth0: 23 0000a020. <7>eth0: 24 0000a022. <7>eth0: 25 0000a022. <7>eth0: 26 0000a022. <7>eth0: 27 0000a020. <7>eth0: 28 0000a020. <7>eth0: 29 0000a022. <7>eth0: 30 0000a022. <7>eth0: 31 0000a022. From becker@scyld.com Mon Jun 24 14:05:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jun 24 13:05:01 2002 Subject: [eepro100] Re: WATCHDOG timeout In-Reply-To: <5D2136DF3DD5D311AE89009027C67FB0063EDFEC@fmsmsx96.fm.intel.com> Message-ID: On Mon, 24 Jun 2002, Afzal, Naeem M wrote: > I am getting this watchdog timeout on 2.4.17 kernel. Root filesystem is > mounted over NFS. NIC just stops responding frequently. I already checked > eeprom setting and the sleep mode is not set. Could you give me some clue on > how I can debug this issue. What driver version? What is the detection message? What does eepro100-diag --force -a -ee report while the problem is happening? -- 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 naeem.m.afzal@intel.com Mon Jun 24 14:43:03 2002 From: naeem.m.afzal@intel.com (Afzal, Naeem M) Date: Mon Jun 24 13:43:03 2002 Subject: [eepro100] RE: WATCHDOG timeout Message-ID: <5D2136DF3DD5D311AE89009027C67FB0063EDFED@fmsmsx96.fm.intel.com> > > What driver version? > What is the detection message? eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.5.2.1 $ 2000/11/17 Modified by Andrey V. Savochkin and others <4>eth0: Invalid EEPROM checksum 0x552b, check settings before activating this device! <6>eth0: Intel Corp. 82559ER (#2), 00:90:D7:00:10:20, IRQ 15. <6> Board assembly 729757-005, Physical connectors present: RJ45 <6> Primary interface chip i82555 PHY #1. <6> General self-test: passed. <6> Serial sub-system self-test: passed. <6> Internal registers self-test: passed. <6> ROM checksum self-test: passed (0xdbd8681d). > What does > eepro100-diag --force -a -ee > report while the problem is happening? > I compiled eepro100-diag.c for xscale and ran it, it failed at while trying to do if (iopl(3)<0) { perror("Nework adapter diagnosgtic: iopl()"); fprintf(stderr, "This program must be run as root.\n"); return 2; } ignored this part by #if 0, then I was able to run, but gave segment core. I was not running it while this problem was going on but it failed anyway. root@10.3.19.183:~# eepro100-diag --force -a -ee eepro100-diag.c:v2.08 4/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel 82559ER EtherExpressPro/100+ adapter at 0x1ffff80. i82557 chip registers at 0x1ffff80: Segmentation fault > -- > 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 Mon Jun 24 16:50:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jun 24 15:50:01 2002 Subject: [eepro100] RE: WATCHDOG timeout In-Reply-To: <5D2136DF3DD5D311AE89009027C67FB0063EDFED@fmsmsx96.fm.intel.com> Message-ID: On Mon, 24 Jun 2002, Afzal, Naeem M wrote: > From: "Afzal, Naeem M" I note that are from Intel -- you have access to current information, while I have to figure out the chip operation from its behavior. > > What driver version? > > What is the detection message? > > eepro100.c:v1.09j-t 9/29/99 Donald Becker > http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Try a current version, which works around the bugs (at least the ones we know about) in the newer chips. > <4>eth0: Invalid EEPROM checksum 0x552b, check settings before activating > this device! This is curious. Has something changed the EEPROM configuration? > <6>eth0: Intel Corp. 82559ER (#2), 00:90:D7:00:10:20, IRQ 15. > > What does > > eepro100-diag --force -a -ee > > report while the problem is happening? > > > I compiled eepro100-diag.c for xscale and ran it, it failed at while trying > to do Ahhh, I didn't know this was for the Xscale architecture. > if (iopl(3)<0) { > perror("Nework adapter diagnosgtic: iopl()"); > fprintf(stderr, "This program must be run as root.\n"); > return 2; OK, that means your libc doesn't have the functions needed to run diagnostics. Someone should fix that. -- 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 tcmleung@yahoo.com Tue Jun 25 07:26:00 2002 From: tcmleung@yahoo.com (Terence Leung) Date: Tue Jun 25 06:26:00 2002 Subject: [eepro100] wait_for_cmd_done timeout! Message-ID: <20020625102526.55402.qmail@web11607.mail.yahoo.com> I have bought a new computer and install Redhat 7.3 The computer is used as a web server and connected to other computer using a switch. However the computer is unstable. After several minutes, it displays like the following: eepro100 wait_for_cmd_done timeout! Sometimes, the computer would halt. It would happen immediately when I use samba to get a large file(about 20Mb) from linux to window. The computer is Intel Pentium4 processor 2.0GHz, Intel 10/100M LAN,256MB RDRAM. Please help. Thank you. ===== Terence Leung, Mobile: 9273 9176 email: tcmleung@yahoo.com, Homepage:http://tcmleung.uhome.net __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From mjbarnes@cisco.com Tue Jun 25 11:39:00 2002 From: mjbarnes@cisco.com (Michael Barnes) Date: Tue Jun 25 10:39:00 2002 Subject: [eepro100] wait_for_cmd_done timeout! References: <20020625102526.55402.qmail@web11607.mail.yahoo.com> Message-ID: <3D18805E.5270A883@cisco.com> I just had this problem myself. Get eepro100-diag.c from http://www.scyld.com/diag. Compile it and run eepro100-diag -ee to see if PCI sleep mode is enabled. If it is, then do eepro100-diag -G 0 -w -w -f to turn it off. You must then do a cold boot. Terence Leung wrote: > > I have bought a new computer and install Redhat 7.3 > The computer is used as a web server and connected to > other computer using a switch. > > However the computer is unstable. After several > minutes, it displays like the following: > > eepro100 wait_for_cmd_done timeout! > > Sometimes, the computer would halt. > > It would happen immediately when I use samba to get > a large file(about 20Mb) from linux to window. > > The computer is Intel Pentium4 processor 2.0GHz, > Intel 10/100M LAN,256MB RDRAM. > > Please help. Thank you. > > > ===== > Terence Leung, > Mobile: 9273 9176 > email: tcmleung@yahoo.com, > Homepage:http://tcmleung.uhome.net > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 -- Michael Barnes Core IP Eng - Routing 408-525-2785 From John.Olson@nationalcity.com Wed Jun 26 14:41:01 2002 From: John.Olson@nationalcity.com (Olson, John C) Date: Wed Jun 26 13:41:01 2002 Subject: [eepro100] eepro100 on SuSE Linux Message-ID: Hello, I'm running SuSE 7.3 professional (2.4.16 kernel) on a compaq ML370 with Compaq nc3131 NIC's. I've compiled and installed eepro100 version 1.23 and mii-diag version 2.04 (along with pci-scan version 1.08). I am finding that I am getting a 100mb half-duplex setting on a card that should be 100/full. When I run mii-diag, it gives me this information. When I try to force the setting (mii-diag -F 100baseTx-FD eth0), I get the following return: Setting the speed to "fixed", Control register 2100. SIOCSMIIREG on eth0 failed: Operation not permitted Basic registers of MII PHY #1: 2000 780d 02a8 0150 05e1 0081 0000 ffff. Basic mode control register 0x2000: Auto-negotiation disabled, with Speed fixed at 100 mbps, half-duplex. You have link beat, and everything is working OK. Your link partner is generating 100baseTx link beat (no autonegotiation). End of basic transceiver information. Have also tried to set this in /etc/modules.conf (options eepro100 debug=1 options=0x2100 full_duplex=1) with no success. Can anyone help me with what is going wrong? > Thanks, > John From becker@scyld.com Wed Jun 26 15:36:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 26 14:36:00 2002 Subject: [eepro100] eepro100 on SuSE Linux In-Reply-To: Message-ID: On Wed, 26 Jun 2002, Olson, John C wrote: > I'm running SuSE 7.3 professional (2.4.16 kernel) on a compaq ML370 with > Compaq nc3131 NIC's. I've compiled and installed eepro100 version 1.23 and > mii-diag version 2.04 (along with pci-scan version 1.08). I am finding that > I am getting a 100mb half-duplex setting on a card that should be 100/full. Why should it be full duplex? Setting to forced-full-duplex should never be used. If autonegotiation is broken with your switch, you should use half duplex. > When I try to force the setting (mii-diag -F 100baseTx-FD eth0), I get the > following return: > Setting the speed to "fixed", Control register 2100. > SIOCSMIIREG on eth0 failed: Operation not permitted You must be 'root' to change the setting. (More precisely, you must have the CAP_NET_ADMIN capability.) > Basic registers of MII PHY #1: 2000 780d 02a8 0150 05e1 0081 0000 > Basic mode control register 0x2000: Auto-negotiation disabled, with > Speed fixed at 100 mbps, half-duplex. Urrgggg. You have set the speed to forced half duplex. > Your link partner is generating 100baseTx link beat (no > autonegotiation). > Have also tried to set this in /etc/modules.conf (options eepro100 debug=1 > options=0x2100 full_duplex=1) with no success. Huh? Using options=0x100 sets the transceiver to forced 100-half. You could use options=0x200, but you should just use mii-diag as root. -- 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 John.Olson@nationalcity.com Wed Jun 26 17:24:01 2002 From: John.Olson@nationalcity.com (Olson, John C) Date: Wed Jun 26 16:24:01 2002 Subject: [eepro100] eepro100 on SuSE Linux Message-ID: All the switch ports here are hard-coded for 100/Full. That's why I'm trying for that particular setting. I am running mii-diag as root, and that is what I get. How do I check / set CAP_NET_ADMIN capability? I tried setting options to 0x200 (as in the doc) but that didn't work either. Forgot to mention that in my original posting. -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Wednesday, June 26, 2002 2:33 PM To: Olson, John C Cc: 'eepro100@scyld.com' Subject: Re: [eepro100] eepro100 on SuSE Linux On Wed, 26 Jun 2002, Olson, John C wrote: > I'm running SuSE 7.3 professional (2.4.16 kernel) on a compaq ML370 with > Compaq nc3131 NIC's. I've compiled and installed eepro100 version 1.23 and > mii-diag version 2.04 (along with pci-scan version 1.08). I am finding that > I am getting a 100mb half-duplex setting on a card that should be 100/full. Why should it be full duplex? Setting to forced-full-duplex should never be used. If autonegotiation is broken with your switch, you should use half duplex. > When I try to force the setting (mii-diag -F 100baseTx-FD eth0), I get the > following return: > Setting the speed to "fixed", Control register 2100. > SIOCSMIIREG on eth0 failed: Operation not permitted You must be 'root' to change the setting. (More precisely, you must have the CAP_NET_ADMIN capability.) > Basic registers of MII PHY #1: 2000 780d 02a8 0150 05e1 0081 0000 > Basic mode control register 0x2000: Auto-negotiation disabled, with > Speed fixed at 100 mbps, half-duplex. Urrgggg. You have set the speed to forced half duplex. > Your link partner is generating 100baseTx link beat (no > autonegotiation). > Have also tried to set this in /etc/modules.conf (options eepro100 debug=1 > options=0x2100 full_duplex=1) with no success. Huh? Using options=0x100 sets the transceiver to forced 100-half. You could use options=0x200, but you should just use mii-diag as root. -- 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 Jun 26 18:21:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jun 26 17:21:00 2002 Subject: [eepro100] eepro100 on SuSE Linux In-Reply-To: Message-ID: On Wed, 26 Jun 2002, Olson, John C wrote: > All the switch ports here are hard-coded for 100/Full. That's why I'm > trying for that particular setting. OK, then FDX is valid, but you should slap the network admin around for doing forced-full-duplex. > I am running mii-diag as root, and that is what I get. How do I check / set > CAP_NET_ADMIN capability? In a normal Linux system all capabilities should be set when you are root. Try doing mii-diag -A 0x01e1 That's not the setting you want, but it will verify that the transceiver write isn't working. > I tried setting options to 0x200 (as in the doc) but that didn't work > either. Forgot to mention that in my original posting. What is the 'mii-diag' output? Try both options=0x200 and options=0x200 full_duplex=1 The options=0x200 should override, but... > > Basic registers of MII PHY #1: 2000 780d 02a8 0150 05e1 0081 0000 > > Basic mode control register 0x2000: Auto-negotiation disabled, with > > Speed fixed at 100 mbps, half-duplex. -- 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 John.Olson@nationalcity.com Thu Jun 27 15:04:03 2002 From: John.Olson@nationalcity.com (Olson, John C) Date: Thu Jun 27 14:04:03 2002 Subject: [eepro100] eepro100 on SuSE Linux Message-ID: Ok, with your help and a little tinkering, it seems to be working. Thanks! Next question: Trying to implement NIC bonding on the same machine and it seems to be starting up ok. However, when I run mii-diag against the bonded virtual NIC, I get the following: # mii-diag bond0 Basic registers of MII PHY #0: 0000 0004 0004 0004 0004 0004 0004 0004. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-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. The registers value looks a little funny to me. Also when I try to manually set the mode of bond0 to 100/full (donald, don't kill me please :), I get the following: # mii-diag -F 100baseTx-FD bond0 Setting the speed to "fixed", Control register 2100. SIOCSMIIREG on bond0 failed: Operation not supported Basic registers of MII PHY #0: 0000 0004 0004 0004 0004 0004 0004 0004. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-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. Everything seems to be working alright except for that when I remove one of the network cables, everything gets really slow across the network to and from that machine. I have the bonding module setup with the following options: miimon=100 mode=1 arp_interval=100 I know this is probably not a function of this particular mail list but I'm hoping you all might have some insight as to what's going on and how I can improve this situation or at least point me in the right direction. I'm running kernel 2.4.16 on a Compaq ML 370. Thanks, John From gman@gman.infinex.com Thu Jun 27 16:56:01 2002 From: gman@gman.infinex.com (G-man) Date: Thu Jun 27 15:56:01 2002 Subject: [eepro100] Command 0000 was not immediately accepted, BLAH ticks??.. References: <004101c21896$a8cc0860$2224040a@hq.spinner.com> Message-ID: <000901c21e14$68926900$2224040a@hq.spinner.com> so is this warning/error message something I can ignore or does it affect network performance or ???.. thanks :) > on a compaq dl360 w/ 2 1ghz cpus > running rehat 6.2 with 2.2.19-6.2.16enterprise kernel > eepro100 v1.23 6/5/2002 > We have the card and switch running force at 100 FD w/ mii-tool.... > > I've gotten the following message/warning/error(?): > > Command 0000 was not immediately accepted, 141 ticks! > Command 0000 was not immediately accepted, 132 ticks! > Command 0000 was not immediately accepted, 102 ticks! > Command 0000 was not immediately accepted, 106 ticks! > Command 0000 was not immediately accepted, 106 ticks! > Command 0000 was not immediately accepted, 152 ticks! > > Just wanted to find out what this was and what happens when this orrurs.. > thanks.. > > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 > From becker@scyld.com Thu Jun 27 17:46:03 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jun 27 16:46:03 2002 Subject: [eepro100] Command 0000 was not immediately accepted, BLAH ticks??.. In-Reply-To: <000901c21e14$68926900$2224040a@hq.spinner.com> Message-ID: On Thu, 27 Jun 2002, G-man wrote: > so is this warning/error message something I can ignore or does it affect > network performance or ???.. > > Command 0000 was not immediately accepted, 141 ticks! It has a very minor effect. The work of printing out the error message is the major delay. The delay appears only on a few recent versions of the hardware. It doesn't happen on the early chips... -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From gman@gman.infinex.com Thu Jun 27 19:32:02 2002 From: gman@gman.infinex.com (G-man) Date: Thu Jun 27 18:32:02 2002 Subject: [eepro100] eth0: Unknown receiver errors ?? Message-ID: <00de01c21e2a$3d7f2e40$2224040a@hq.spinner.com> Hiyas..me again :).. So I'm getting these errors w/ the eepro100.c:v1.23 6/5/2002 driver.. eth0: Unknown receiver error, status=0x5048. eth0: Unknown receiver error, status=0x5048. eth0: Unknown receiver error, status=0x7048. eth0: Unknown receiver error, status=0x7048. any clues? even though that are "Unknown"... eth0 Link encap:Ethernet HWaddr 00:50:8B:E2:7A:B6 inet addr:10.10.10.112 Bcast:10.10.10.127 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:173493200 errors:9 dropped:0 overruns:0 frame:0 TX packets:256180893 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 Base address:0x4000 From becker@scyld.com Thu Jun 27 20:51:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jun 27 19:51:01 2002 Subject: [eepro100] eth0: Unknown receiver errors ?? In-Reply-To: <00de01c21e2a$3d7f2e40$2224040a@hq.spinner.com> Message-ID: On Thu, 27 Jun 2002, G-man wrote: > Hiyas..me again :).. So I'm getting these errors w/ the eepro100.c:v1.23 > 6/5/2002 driver.. > > eth0: Unknown receiver error, status=0x5048. > eth0: Unknown receiver error, status=0x5048. > eth0: Unknown receiver error, status=0x7048. > eth0: Unknown receiver error, status=0x7048. These are reporting that the chip is out of "Rx resources". This might mean that there is heavy PCI bus contention. But I can't figure out why it's newly appearing. The message has been in the driver for a few versions, and I haven't changed any bus parameters. Bottom line: I'm still tracking it down. -- 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 ianz@quarterleaf.com Fri Jun 28 15:49:01 2002 From: ianz@quarterleaf.com (Ian Zapczynski) Date: Fri Jun 28 14:49:01 2002 Subject: [eepro100] PCI EtherExpress Pro100 82557 "reports no resources" - "no rx buffers" Message-ID: <3D1CAEBC.ECD8EDD8@quarterleaf.com> Hello all. I'm hoping someone here can kick me in the right direction. We have two VA Linux machines running VA's version of Red Hat 6.2 that include Intel PCI EtherExpress Pro100 82557 cards which we have experienced some problems with. My problem is that seemingly without cause, we'll get the following errors on the console and in /var/log/messages: kernel: eth1: card reports no resources. kernel: eth1: card reports no RX buffers. Sometimes the errors refer to eth0, other times they refer to eth1. Both are Intel Pro100 NICs, though one is on-board while the other is a PCI card. Sometimes when the errors appear, the machine is then knocked off the network. In some cases a reboot will resolve the issue, but once it took two reboots and some patience. In searching for the error messages, I came across this older post on this mailing list: http://www.scyld.com/pipermail/eepro100/2000-July/001135.html While this post refers specifically to the 82559 chip, I assumed I should upgrade the driver first before anything else. Long story short, I couldn't successfully get the Intel driver compiled on my machine. So I came back to www.scyld.com to download the latest driver available there and see if I'd have better luck. I placed eepro100.c, kern_compat.h, pci-scan.c, and pci-scan.h in /usr/src/modules and issued the included compile commands (with appropriate -I flags added). When doing so, I got: In file included from eepro100.c:133: kern_compat.h:63: stray '\' in program kern_compat.h:64: parse error before `license' eepro100.c:146: stray '\' in program eepro100.c: In function `speedo_open': eepro100.c:874: `NETIF_MSG_IFUP' undeclared (first use in this function) eepro100.c:874: (Each undeclared identifier is reported only once eepro100.c:874: for each function it appears in.) eepro100.c: In function `speedo_timer': eepro100.c:1017: `NETIF_MSG_TIMER' undeclared (first use in this function) as well as several other complaints of failed declarations. Unfortunately, I am not familiar with C code, so my feeble attempts to fix what I hoped to be a blatant syntax error in kern_compat.h failed. According to uname -r, my kernel version is 2.2.18pre11-va2.1smp. Would anyone be so kind as to help me understand: 1) what I might do to get the driver compiled on my machine 2) if I should be looking at something else as a cause of the "card reports no resources" errors other than an outdated driver and available RAM (of which there is plenty) 3) in general, what I could be doing that is terribly stupid Thank you in advance for the help! One of these machines is in production, so it would be very helpful if I can find a solution to this problem. Unfortunately the problem didn't exhibit itself until nearly a year after being put into that environment. -Ian From becker@scyld.com Fri Jun 28 17:33:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jun 28 16:33:01 2002 Subject: [eepro100] PCI EtherExpress Pro100 82557 "reports no resources" - "no rx buffers" In-Reply-To: <3D1CAEBC.ECD8EDD8@quarterleaf.com> Message-ID: On Fri, 28 Jun 2002, Ian Zapczynski wrote: > In file included from eepro100.c:133: > kern_compat.h:63: stray '\' in program > kern_compat.h:64: parse error before `license' Something corrupted your download, likely a web browser. Use 'ftp' ncftpget ftp://www.scyld.com/pub/network/kern_compat.h -- 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 qube00@yahoo.com Sat Jun 29 14:01:01 2002 From: qube00@yahoo.com (krishna kumar rangan) Date: Sat Jun 29 13:01:01 2002 Subject: [eepro100] eepro100 question Message-ID: <20020629170039.95922.qmail@web12204.mail.yahoo.com> hi, A quick question in inserting the pci-scan module prior to the inserting the eepro100 module. I obtained both these source files from scyld's network drivers page and compiled them with the options mentioned in their sources. when I try to insert the pci-scan module into the running kernel, I get the following symbols missing error. I am running a redhat 7.3 package, kernel 2.4.18-3. -- begin message ./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 ./pci-scan.o: Hint: You are trying to load a module without a GPL compatible license and it has unresolved symbols. Contact the module supplier for assistance, only they can help you. -- end message Does pci-scan itself require other modules? thank you for your time and help. regards, -krishna. ps: the eepro100 driver that is shipped with redhat 7.3 seems to bail out with wait_cmd_on_timeout warning after a few mintues, which is why i am trying to replace with the one above. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com