From mastermnd@mastermnd.myip.org Wed May 1 14:26:01 2002 From: mastermnd@mastermnd.myip.org (mastermnd@mastermnd.myip.org) Date: Wed May 1 13:26:01 2002 Subject: [eepro100] wait_for_cmd_done timeout! In-Reply-To: References: <20020430214118.GA2035@mastermnd.myip.org> Message-ID: <20020501172545.GA14472@mastermnd.myip.org> On Tue, Apr 30, 2002 at 05:49:35PM -0400, Donald Becker wrote: > On Tue, 30 Apr 2002, Brian Johnson wrote: > > > Subject: [eepro100] wait_for_cmd_done timeout! > > > > Hi, I'm getting this error. > > I read the archives, and noticed a few other people seem to be having > > this problem. > > There are several problems that can cause this message. > > What driver are you using? > Run 'eepro100-diag -a' when the interface stops to see the status. > > > I'm on a 10 baseT hub and using DHCP. > > Have you run 'eepro100-diag -ee' to verify that sleep mode is not > enabled? --end quoted text--- Yes, sleep mode was enabled. It did take some work to get it to disable. I ended-up having to 'ifconfig eth0 down' and 'rmmod eepro100' then 'insmod eepro100' then run 'eepro100-diag -G 0 -w -w -f' then when I called 'eepro100-diag -ee -f' it finally didn't say sleep mode was enabled. no matter what I do I always seem to need the -f flag. if I just shut down eth0 and didn't rmmod/insmod then the sleep mode setting wouldn't stick. But in the end it worked great, I finally have an uptime > 4 hours! :) Many thanks for the assistance! -- Brian Johnson From anand@eis.iisc.ernet.in Wed May 1 14:30:01 2002 From: anand@eis.iisc.ernet.in (S.V.R. Anand) Date: Wed May 1 13:30:01 2002 Subject: [eepro100] kernel:eth0: card reports no resources Message-ID: <3CD02D67.7546BA67@eis.iisc.ernet.in> Hi, I have two 100Mbps LAN segments connected by a Linux (2.4.2) machine (Pentium III @ 500MHz) acting as a router having two eepro100 cards. I conducted a sort of stress test by pumping tcp packets using ttcp program from a host on one segment to a host on another segment. The mtu I set on the end hosts is 80 bytes. The moment I started the program the router started giving the error kernel:eth0: card reports no resources kernel:eth1: card reports no resources How do I make sure I don't get the above error ? Anand From TRobert459@aol.com Thu May 2 13:17:02 2002 From: TRobert459@aol.com (TRobert459@aol.com) Date: Thu May 2 12:17:02 2002 Subject: [eepro100] eepro100 ( and pci_scan) gives unresolved symbols errors Message-ID: <02755A5A.2F5A3173.0C51FD60@aol.com> Hi, I am trying to use the latest eepro100 from the www.scyld.com on a minimal linux system but I am receiving a number of unresolved symbol errors when I try to load pci_scan. The unresolved symbols include things like softnet_data_R34d7fb3a, pci_drv_unregister, acpi_set_pwr_state and more. The pci_scan ( and eepro100 ) load fine on a complete version of the RH7.1 linux( 2.4.12). The cutdown linux is based on this build. What is the easiest was to findout what is missing from the cutdown linux system ? Regards Tom Robertson From Petrov M.I." Hi All! I have onboard intel 82559 card & installed modulee eepro100. Now this card stop work! I have nothing log & informations. The `ping' don't answer. When I do `rmmod eepro100' I see: device is busy. When I reboot my computer - ethernet work but then it again stop to work. I don't why. I have RedHat 7.0 & kernel 2.2.16-smp. Help me. Thanx. From becker@scyld.com Thu May 2 19:42:02 2002 From: becker@scyld.com (Donald Becker) Date: Thu May 2 18:42:02 2002 Subject: [eepro100] eepro100 ( and pci_scan) gives unresolved symbols errors In-Reply-To: <02755A5A.2F5A3173.0C51FD60@aol.com> Message-ID: On Thu, 2 May 2002 TRobert459@aol.com wrote: > I am trying to use the latest eepro100 from the www.scyld.com on a > minimal linux system but I am receiving a number of unresolved symbol > errors when I try to load pci_scan. The unresolved symbols include > things like softnet_data_R34d7fb3a, pci_drv_unregister, > acpi_set_pwr_state and more. You compiled against the wrong header files. Look at the Makefile ftp://www.scyld.com/pub/network/Makefile to see where your new kernel should put its header files. > The pci_scan ( and eepro100 ) load fine > on a complete version of the RH7.1 linux( 2.4.12). The cutdown linux > is based on this build. What is the easiest was to findout what is > missing from the cutdown linux system ? Nothing is missing. The problem is the unexpected place that Red Hat wants to put the header files for the currently running kernel. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Thu May 2 19:45:51 2002 From: becker@scyld.com (Donald Becker) Date: Thu May 2 18:45:51 2002 Subject: [eepro100] I have problem my intell 82559 card. In-Reply-To: Message-ID: On Thu, 2 May 2002, Petrov M.I. wrote: > I have onboard intel 82559 card & installed modulee eepro100. > Now this card stop work! I have nothing log & informations. > The `ping' don't answer. When I do `rmmod eepro100' I see: > device is busy. When I reboot my computer - ethernet work but > then it again stop to work. I don't why. > I have RedHat 7.0 & kernel 2.2.16-smp. You have to shut down the interface ifconfig eth0 down before you can remove the module. What driver version? What is the detection message? What does eepro100-diag -aee report when the interface isn't working? -- 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 kallol@efi.com Thu May 2 20:04:48 2002 From: kallol@efi.com (Kallol Biswas) Date: Thu May 2 19:04:48 2002 Subject: [eepro100] Multicast testing References: Message-ID: <3CD1AA3A.EE07468B@efi.com> I don't remember if I asked this question before. Which tool people generally use for multicast functionality testing on a linux driver? Kallol From Petrov M.I." Message-ID: Hi All! Hi Donald! Thanks for help me. > > I have onboard intel 82559 card & installed modulee eepro100. > > Now this card stop work! I have nothing log & informations. > > The `ping' don't answer. When I do `rmmod eepro100' I see: > > device is busy. When I reboot my computer - ethernet work but > > then it again stop to work. I don't why. > > I have RedHat 7.0 & kernel 2.2.16-smp. > > You have to shut down the interface > ifconfig eth0 down > before you can remove the module. Yes. I do: ifconfig eth0 down ifconfig eth0 up and eth0 interface again work, but in some time it again stop work. > > What driver version? "eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n" "eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin and others\n"; > What is the detection message? In my log/message: May 1 20:03:33 yuri kernel: Board assembly 123456-120, Physical connectors present: RJ45 May 1 20:03:33 jury kernel: Primary interface chip i82555 PHY #1. May 1 20:03:33 jury kernel: General self-test: passed. May 1 20:03:33 jury kernel: Serial sub-system self-test: passed. May 1 20:03:33 jury kernel: Internal registers self-test: passed. May 1 20:03:33 jury kernel: ROM checksum self-test: passed (0x04f4518b). May 1 20:03:33 jury kernel: Receiver lock-up workaround activated. May 1 20:03:33 jury kernel: eth1: OEM i82557/i82558 10/100 Ethernet, 00:E0:81:01:70:7B, I/O at 0xd000, IRQ 21. May 1 20:03:33 jury kernel: Board assembly 123456-120, Physical connectors present: RJ45 May 1 20:03:33 jury kernel: Primary interface chip i82555 PHY #1. May 1 20:03:33 jury kernel: General self-test: passed. May 1 20:03:33 jury kernel: Serial sub-system self-test: passed. May 1 20:03:33 jury kernel: Internal registers self-test: passed. May 1 20:03:33 jury kernel: ROM checksum self-test: passed (0x04f4518b). May 1 20:03:33 jury kernel: Receiver lock-up workaround activated. /sbin/ifconfig: eth0 Link encap:Ethernet HWaddr 00:E0:81:01:70:7A inet addr:194.44.215.102 Bcast:194.44.215.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:68111 errors:0 dropped:0 overruns:0 frame:0 TX packets:30907 errors:0 dropped:0 overruns:3 carrier:0 collisions:0 txqueuelen:100 Interrupt:20 Base address:0xd400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:2188 errors:0 dropped:0 overruns:0 frame:0 TX packets:2188 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 > What does > eepro100-diag -aee > report when the interface isn't working? : eepro100-diag.c:v2.07 12/28/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xd400. A potential i82557 chip has been found, but it appears to be active. Either shutdown the network, or use the '-f' flag. Index #2: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xd000. i82557 chip registers at 0xd000: 00000000 00000000 00000000 00080002 10000000 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. EEPROM contents, size 64x16: 00: e000 0181 7b70 0100 0003 0301 0701 0000 0x08: 1234 5678 40a2 000c 8086 0000 0000 0000 ... 0x30: 0120 4000 3004 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 b7c0 The EEPROM checksum is correct. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:E0:81:01:70:7B. Receiver lock-up bug exists. (The driver work-around *is* implemented.) Board assembly 123456-120, 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. Thanks. From becker@scyld.com Fri May 3 13:24:02 2002 From: becker@scyld.com (Donald Becker) Date: Fri May 3 12:24:02 2002 Subject: Re[2]: [eepro100] I have problem my intell 82559 card. In-Reply-To: Message-ID: On Fri, 3 May 2002, Petrov M.I. wrote: > > What driver version? > > "eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n" > "eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin and others\n"; This is an old driver version. Note that I don't support modified drivers. > > What does > > eepro100-diag -aee > > report when the interface isn't working? > : > eepro100-diag.c:v2.07 12/28/2001 Donald Becker (becker@scyld.com) ... > 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. Follow these directions for both interfaces. The updated driver is at http://www.scyld.com/network/eepro100.html ftp://www.scyld.com/pub/network/eepro100.c -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From bradd@us.ibm.com Tue May 7 11:47:02 2002 From: bradd@us.ibm.com (Brad DesAulniers) Date: Tue May 7 10:47:02 2002 Subject: [eepro100] eepro100 problems Message-ID: I'm getting terrible performance with my onboard Intel ethernet "card". It's on an IBM Thinkpad T21. I get 2.7 kb downloads from a particular web site. When I change to a pcmcia 3COM card, I get 1mb downloads from the same site. I've tested this about 10 times. It's very consistent (100% of the time). When I run ifconfig eth0, I see lots of frame errors and overruns. I've tried the version of eepro100.o from RedHat kernel 2.4.17 and 2.4.18, as well as the latest code from sycld. All three versions give the same error. Any suggestions? Thanks! Brad DesAulniers bradd@us.ibm.com From mojorsn@wwd.net Wed May 8 00:08:12 2002 From: mojorsn@wwd.net (Doris Leng) Date: Tue May 7 23:08:12 2002 Subject: [eepro100] eeprm,Feeling Old? We Can Help! Message-ID: <200205080306.g48361O07382@blueraja.scyld.com> Hello, eeprm@netscape.net

As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!


* Reduce body fat and build lean muscle WITHOUT EXERCISE!
* Enhace sexual performance
* Remove wrinkles and cellulite
* Lower blood pressure and improve cholesterol profile
* Improve sleep, vision and memory
* Restore hair color and growth
* Strengthen the immune system
* Increase energy and cardiac output
* Turn back your body's biological time clock 10-20 years
in 6 months of usage !!!

FOR FREE INFORMATION AND GET FREE 1 MONTH SUPPLY OF HGH CLICK HERE















You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here From jjh@ecs.soton.ac.uk Wed May 8 12:40:01 2002 From: jjh@ecs.soton.ac.uk (Jon. Hallett) Date: Wed May 8 11:40:01 2002 Subject: [eepro100] eepro100 failing under load Message-ID: <5.1.0.14.2.20020508160754.028cf9d8@roadrunner.ecs.soton.ac.uk> We are having major problems with two PC's with Intel Ether Express Pro 100 server adapters. When put under load, the adapters stop working. We can reliably make the adapters fail by attempting to back up the machines to a remote tape drive. Any other heavy network use also makes them fail. The two machines are both running a 2.4.9 kernel with the 1.20 eepro100 driver: Linux roadrunner 2.4.9-31enterprise #1 SMP Tue Feb 26 06:25:36 EST 2002 i686 unknown May 8 16:07:38 roadrunner kernel: eepro100.c:v1.20 1/28/2002 Donald Becker May 8 16:07:38 roadrunner kernel: http://www.scyld.com/network/eepro100.html May 8 16:07:38 roadrunner kernel: eth0: OEM Intel i82559 rev 8 at 0xf89a7000, 00:30:48:11:09:37, IRQ 31. May 8 16:07:38 roadrunner kernel: Board assembly 000000-000, Physical connectors present: RJ45 May 8 16:07:38 roadrunner kernel: Primary interface chip i82555 PHY #1. May 8 16:07:38 roadrunner kernel: General self-test: passed. May 8 16:07:38 roadrunner kernel: Serial sub-system self-test: passed. May 8 16:07:38 roadrunner kernel: Internal registers self-test: passed. May 8 16:07:38 roadrunner kernel: ROM checksum self-test: passed (0x04f4518b). When the interfaces fail, lots of these messages appear in /var/log/messages: May 8 16:04:42 roadrunner kernel: eth0: Transmit timed out: status 0000 0010 at 530/550 commands 000c0000 000c0000 000c0000. May 8 16:04:42 roadrunner kernel: eth0: Restarting the chip... May 8 16:04:42 roadrunner kernel: Command 0070 was not accepted after 10001 polls! and eepro100-diag -aee -f produces the following: eepro100-diag.c:v2.07 12/28/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xd400. i82557 chip registers at 0xd400: 00100000 36a86300 00000000 00080002 182541e1 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. The Command register has an unprocessed command 0010(?!). EEPROM contents, size 64x16: 00: 3000 1148 3709 0d1b 0000 0201 4701 0000 0x08: 0000 0000 48e0 100c 8086 0000 0000 0000 ... 0x38: 0000 0000 0000 0000 0000 0000 0000 12da The EEPROM checksum is correct. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:30:48:11:09:37. Board assembly 000000-000, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Any ideas what is going wrong? We get the same problem with the RedHat supplied versions of eepro100 and e100 and with the latest Intel supplied version of e100. Note that we can reliably reproduce the problem, and we'd be entirely happy to experiment with updated drivers. Thanks, Jon. From joe@netli.com Wed May 8 15:41:02 2002 From: joe@netli.com (Joe Rouvier) Date: Wed May 8 14:41:02 2002 Subject: [eepro100] mii-diag strangeness Message-ID: <1020883223.1332.154.camel@trance> I'm having a strange problem with mii-diag on IBM Netfinity 4000R's. It seems that mii-diag works fine as a non-root user, but reads all nulls when run as root, and fails to force an interface to a specific mode, etc. This problem is reproducable on different boxes. Mii-diag compiled with and without libmii.c return the same result. These boxes use a pair of 82557s. Testing was done on kernel 2.4.9 with the nic driver loaded as a module. eepro-diag works fine (as root) One item of note. The Netfinity 4000R uses almost exactly the same motherboard as the Network Engines WebEngine, but with a different BIOS. The problem does not happen on WebEngine boxes. Any thoughts? Diagnostics follow: ---- As non-root: mii-diag.c:v2.03 11/5/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver information. MII PHY #1 transceiver registers: 3000 782d 02a8 0154 05e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0a03 0000 0001 0000 0000 0000 0000 0000 0000 0000 0b10 0000 0000 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 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. ----- As Root: mii-diag.c:v2.03 11/5/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x0000 ... 0000. Link status: not established. This transceiver is capable of . Unable to perform Auto-negotiation, negotiation not complete. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. MII PHY #0 transceiver registers: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled! Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x0000 ... 0000. Link status: not established. Capable of . Unable to perform Auto-negotiation, negotiation not complete. This transceiver has no vendor identification. I'm advertising 0000: Advertising no additional info pages. Using an unknown (non 802.3) encapsulation. Link partner capability is 0000:. Negotiation did not complete. ----- eepro-diag output: eepro100-diag.c:v2.07 12/28/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0x2040. i82557 chip registers at 0x2040: 0c000090 0fb19000 00000000 00080002 182545e1 00000600 No interrupt sources are pending. The transmit unit state is 'Active'. The receive unit state is 'Ready'. This status is unusual for an activated interface. The Command register has an unprocessed command 0c00(?!). Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:06:29:DE:D4:79. Board assembly 001024-010, 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. MII PHY #1 transceiver registers: 3000 782d 02a8 0154 05e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0a03 0000 0001 0000 0000 0000 0000 0000 0000 0000 0b10 0000 0000 0000 0000 0000. MII PHY #1 transceiver registers: 3000 782d 02a8 0154 05e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0a03 0000 0001 0000 0000 0000 0000 0000 0000 0000 0b10 0000 0000 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 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. -- Joe Rouvier Systems Administrator Netli.com (650)812-0565 x131 From becker@scyld.com Wed May 8 23:51:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed May 8 22:51:01 2002 Subject: [eepro100] mii-diag strangeness In-Reply-To: <1020883223.1332.154.camel@trance> Message-ID: On 8 May 2002, Joe Rouvier wrote: > I'm having a strange problem with mii-diag on IBM Netfinity 4000R's. It > seems that mii-diag works fine as a non-root user, but reads all nulls > when run as root, and fails to force an interface to a specific mode, > etc. This problem is reproducable on different boxes. Mii-diag > compiled with and without libmii.c return the same result. Hmmm, this is curious. My drivers only check for 'root' with MII writes, not reads. What driver version are you using? > One item of note. The Netfinity 4000R uses almost exactly the same > motherboard as the Network Engines WebEngine, but with a different > BIOS. The problem does not happen on WebEngine boxes. That's very strange! > eepro-diag output: ... > Intel EtherExpress Pro 10/100 EEPROM contents: > Station address 00:06:29:DE:D4:79. > Board assembly 001024-010, 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. You should pay attention to this. -- 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 joe@netli.com Thu May 9 00:06:01 2002 From: joe@netli.com (Joe Rouvier) Date: Wed May 8 23:06:01 2002 Subject: [eepro100] mii-diag strangeness In-Reply-To: References: Message-ID: <1020913549.22114.10.camel@trance> On Wed, 2002-05-08 at 19:50, Donald Becker wrote: > On 8 May 2002, Joe Rouvier wrote: > > > I'm having a strange problem with mii-diag on IBM Netfinity 4000R's. It > > seems that mii-diag works fine as a non-root user, but reads all nulls > > when run as root, and fails to force an interface to a specific mode, > > etc. This problem is reproducable on different boxes. Mii-diag > > compiled with and without libmii.c return the same result. > > Hmmm, this is curious. > My drivers only check for 'root' with MII writes, not reads. > What driver version are you using? eepro100.c:v1.09j-t 9/29/99... eepro100.c: $Revision: 1.36 $ 2000/11/17... As distributed with linux kernel 2.4.9 and: mii-diag.c:v2.03 11/5/2001 libmii.c:v2.04 5/16/2001 eepro100-diag.c:v2.07 12/28/2001 > > One item of note. The Netfinity 4000R uses almost exactly the same > > motherboard as the Network Engines WebEngine, but with a different > > BIOS. The problem does not happen on WebEngine boxes. > > That's very strange! > > > eepro-diag output: > ... > > Intel EtherExpress Pro 10/100 EEPROM contents: > > Station address 00:06:29:DE:D4:79. > > Board assembly 001024-010, 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. > > You should pay attention to this. Oops, yeah, I should. -- Joe Rouvier Systems Administrator Netli.com (650)812-0565 x131 From webmaster-admin@linux.org.tw Thu May 9 08:19:01 2002 From: webmaster-admin@linux.org.tw (webmaster-admin@linux.org.tw) Date: Thu May 9 07:19:01 2002 Subject: [eepro100] Your message to Webmaster awaits moderator approval Message-ID: <20020509111801.CDAFB1F96B@tlug.sinica.edu.tw> Your mail to 'Webmaster' with the subject Of Service Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 140269 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. From martin@trymedia.com Thu May 9 11:00:01 2002 From: martin@trymedia.com (Javier Martin) Date: Thu May 9 10:00:01 2002 Subject: [eepro100] eepro100 overrun errors Message-ID: Hi, I'm having overrun errors in the following configuration: stock redhat 7.2 with: kernel 2.4.7 net-tools (ifconfig) 1.60 This is a DELL 1300 computer that has two EEPRO100, one built-in (eth0, which works perfectly) and an extra PCI card (eth1), which has the problem of TX overruns. # ifconfig eth0 Link encap:Ethernet HWaddr 00:B0:D0:21:0B:23 inet addr:192.168.2.151 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2979 errors:0 dropped:0 overruns:0 frame:0 TX packets:1928 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:290272 (283.4 Kb) TX bytes:284558 (277.8 Kb) Interrupt:11 Base address:0x3000 eth1 Link encap:Ethernet HWaddr 00:90:27:DC:8C:B7 inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:28 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:1176 (1.1 Kb) Interrupt:14 Base address:0x5000 Any idea? Javier From martin@trymedia.com Thu May 9 14:26:37 2002 From: martin@trymedia.com (Javier Martin) Date: Thu May 9 13:26:37 2002 Subject: [eepro100] eepro100 overrun errors In-Reply-To: Message-ID: Answering to myself... I just installed the drivers from intel: http://support.intel.com/support/network/adapter/pro100/31351.htm#e100-x.x.x .tar.gz And overruns have disappeared. Javier > -----Original Message----- > From: eepro100-admin@scyld.com [mailto:eepro100-admin@scyld.com]On > Behalf Of Javier Martin > Sent: Thursday, May 09, 2002 4:01 PM > To: eepro100@scyld.com > Subject: [eepro100] eepro100 overrun errors > > > Hi, > > I'm having overrun errors in the following configuration: > > stock redhat 7.2 with: > kernel 2.4.7 > net-tools (ifconfig) 1.60 > > This is a DELL 1300 computer that has two EEPRO100, one built-in (eth0, > which works perfectly) and an extra PCI card (eth1), which has the problem > of TX overruns. > > # ifconfig > eth0 Link encap:Ethernet HWaddr 00:B0:D0:21:0B:23 > inet addr:192.168.2.151 Bcast:192.168.2.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:2979 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1928 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:290272 (283.4 Kb) TX bytes:284558 (277.8 Kb) > Interrupt:11 Base address:0x3000 > > eth1 Link encap:Ethernet HWaddr 00:90:27:DC:8C:B7 > inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:28 errors:0 dropped:0 overruns:28 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:0 (0.0 b) TX bytes:1176 (1.1 Kb) > Interrupt:14 Base address:0x5000 > > > Any idea? > > Javier > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 From joe@netli.com Thu May 9 17:23:01 2002 From: joe@netli.com (Joe Rouvier) Date: Thu May 9 16:23:01 2002 Subject: [eepro100] mii-diag strangeness In-Reply-To: References: Message-ID: <1020975775.9202.25.camel@trance> On Wed, 2002-05-08 at 19:50, Donald Becker wrote: > On 8 May 2002, Joe Rouvier wrote: > > > I'm having a strange problem with mii-diag on IBM Netfinity 4000R's. It > > seems that mii-diag works fine as a non-root user, but reads all nulls > > when run as root, and fails to force an interface to a specific mode, > > etc. This problem is reproducable on different boxes. Mii-diag > > compiled with and without libmii.c return the same result. > > Hmmm, this is curious. > My drivers only check for 'root' with MII writes, not reads. > What driver version are you using? > > > One item of note. The Netfinity 4000R uses almost exactly the same > > motherboard as the Network Engines WebEngine, but with a different > > BIOS. The problem does not happen on WebEngine boxes. > > That's very strange! I did some more checking on this. It seems my earlier assumptions were incorrect. Mii-diag fails on both the Network Engines and the IBMs, but only with the latest version, v2.02 is fine: 0 a1-dca-qwest darkness /home/darkness > sudo /usr/local/bin/mii-diag -V mii-diag.c:v2.03 11/5/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. Basic registers of MII PHY #0: 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x0000 ... 0000. Link status: not established. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. 0 a1-dca-qwest darkness /home/darkness > sudo /root/mii-diag -V mii-diag.c:v2.02 5/21/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 41e1 0001 0000. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. End of basic transceiver information. -- Joe Rouvier Systems Administrator Netli.com (650)812-0565 x131 From becker@scyld.com Thu May 9 20:31:02 2002 From: becker@scyld.com (Donald Becker) Date: Thu May 9 19:31:02 2002 Subject: [eepro100] mii-diag strangeness In-Reply-To: <1020975775.9202.25.camel@trance> Message-ID: On 9 May 2002, Joe Rouvier wrote: > On Wed, 2002-05-08 at 19:50, Donald Becker wrote: > > On 8 May 2002, Joe Rouvier wrote: > > > > > I'm having a strange problem with mii-diag on IBM Netfinity 4000R's. It > > > seems that mii-diag works fine as a non-root user, but reads all nulls > > > when run as root, ... > I did some more checking on this. It seems my earlier assumptions were > incorrect. Mii-diag fails on both the Network Engines and the IBMs, but > only with the latest version, v2.02 is fine: OK, that explains part of the problem. The MII ioctl() constants were changed for the 2.4 kernel. Yes, the symbolic name that was supposed to represent a constant changed value yet kept the same name. The v2.02 'mii-diag' program always uses the symbolic constant, which now changes depending on the system that it's compiled on. The v2.03 'mii-diag' program tries both the new and old symbolic values. If the new value seems to return valid data, it uses the new, otherwise it uses the old. I've updated 'mii-diag' so that passing the '-v' flag will report which value is being used. Look for this in v2.04. What driver and kernel version are you using? > mii-diag.c:v2.03 11/5/2001 Donald Becker (becker@scyld.com) > Basic registers of MII PHY #0: 0000 0000 0000 0000 0000 0000 0000 0000. ... > mii-diag.c:v2.02 5/21/2001 Donald Becker (becker@scyld.com) > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 41e1 0001 0000. Note that 2.03 is trying to read PHY #0, not PHY #1. -- 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 joe@netli.com Thu May 9 21:30:01 2002 From: joe@netli.com (Joe Rouvier) Date: Thu May 9 20:30:01 2002 Subject: [eepro100] mii-diag strangeness In-Reply-To: References: Message-ID: <1020990579.9399.58.camel@trance> On Thu, 2002-05-09 at 16:27, Donald Becker wrote: > On 9 May 2002, Joe Rouvier wrote: > > On Wed, 2002-05-08 at 19:50, Donald Becker wrote: > > > On 8 May 2002, Joe Rouvier wrote: > > > > > > > I'm having a strange problem with mii-diag on IBM Netfinity 4000R's. It > > > > seems that mii-diag works fine as a non-root user, but reads all nulls > > > > when run as root, > ... > > I did some more checking on this. It seems my earlier assumptions were > > incorrect. Mii-diag fails on both the Network Engines and the IBMs, but > > only with the latest version, v2.02 is fine: > > OK, that explains part of the problem. > > What driver and kernel version are you using? eepro100.c:v1.09j-t 9/29/99 ... eepro100.c: $Revision: 1.36 ... Kernel 2.4.9 > > mii-diag.c:v2.03 11/5/2001 Donald Becker (becker@scyld.com) > > Basic registers of MII PHY #0: 0000 0000 0000 0000 0000 0000 0000 0000. > ... > > mii-diag.c:v2.02 5/21/2001 Donald Becker (becker@scyld.com) > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 41e1 0001 0000. > > Note that 2.03 is trying to read PHY #0, not PHY #1. > There are two PHYs on an 82557!? Or is the "real" PHY just offset? -- Joe Rouvier Systems Administrator Netli.com (650)812-0565 x131 From becker@scyld.com Thu May 9 22:38:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu May 9 21:38:01 2002 Subject: [eepro100] mii-diag strangeness In-Reply-To: <1020990579.9399.58.camel@trance> Message-ID: On 9 May 2002, Joe Rouvier wrote: > On Thu, 2002-05-09 at 16:27, Donald Becker wrote: > > On 9 May 2002, Joe Rouvier wrote: > > > On Wed, 2002-05-08 at 19:50, Donald Becker wrote: > > > > On 8 May 2002, Joe Rouvier wrote: > > > > > > > > > I'm having a strange problem with mii-diag on IBM Netfinity 4000R's. It > > > > > seems that mii-diag works fine as a non-root user, but reads all nulls > > > > > when run as root, ... > > What driver and kernel version are you using? > > eepro100.c:v1.09j-t 9/29/99 ... A modification of one of my old releases... > eepro100.c: $Revision: 1.36 ... ...that has been further modified by someone else. This makes it difficult to track the branches and changes. > > > mii-diag.c:v2.03 11/5/2001 Donald Becker (becker@scyld.com) > > > Basic registers of MII PHY #0: 0000 0000 0000 0000 0000 0000 0000 0000. > > ... > > > mii-diag.c:v2.02 5/21/2001 Donald Becker (becker@scyld.com) > > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 41e1 0001 0000. > There are two PHYs on an 82557!? Or is the "real" PHY just offset? PHY #0 is special: it's the address for an external, plug-in transceiver. But here it's likely just that driver version returning to the ioctl() with bogus data. I've updated mii-diag to v2.04. It's in the usual place: ftp://www.scyld.com/pub/diag/ -- 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 eskim@adelinux.com Thu May 9 23:33:02 2002 From: eskim@adelinux.com (Eung-Shik Kim) Date: Thu May 9 22:33:02 2002 Subject: [eepro100] back-porting v1.18 into kernel-2.4.17 Message-ID: <200205100225.g4A2OuPE002642@bbs.adelinux.com> Hi all: I had been working on eepro100.c following version: eepro100.c:v1.18 11/7/2001 Donald Becker For some reason I had to upgrade kernel version from 2.4.2 to 2.4.17. So I think that I had to back-port my modified eepro100.c into kernel-2.4.17. I found out different version of eepro100 between Donald Becker's and Andrey Savochkin's. But I do not know how to back-port. Could someone help me out plz. In addition, which is better solution between back-porting my modified eepro100.c into kernel-2.4.17 and newly modifying Andrey Savochkin's eepro100.c of kernel-2.4.17 based on my work on Donald Becker's eepro100.c v1.18 ? Thanks in advance... From jokerlnx@subdimension.com Sun May 12 15:09:01 2002 From: jokerlnx@subdimension.com (-=> \JokerMaN <=-) Date: Sun May 12 14:09:01 2002 Subject: [eepro100] ibm etherjet Message-ID: <3CDEDA77.3090901@subdimension.com> can someone give me the url of the eepro100 download? i finded one, but it seems broken. i have a ibm etherjet 10/100 management adapter, some tips? thanks joker From stahlbock@basysprint.de Mon May 13 13:36:00 2002 From: stahlbock@basysprint.de (Bernd Stahlbock) Date: Mon May 13 12:36:00 2002 Subject: [eepro100] several eepro problems Message-ID: Dear list, I had to cope with several eepro bugs the last 2 years, with 557,558,559er cards. As I just found out again, most of these problems seem to be due to hardware flaws of the boards they are used in. I worked on several single board / embedded Pc boards. For example the onboard 559er won't run stable, but a add on card with the same 559er on it runs fine with the same boot image and the same mainboard. This is the same that i see for RTL8139 systems as well. Just as a hint: try another hardware, the linux netdrivers won't run stable on some boards were the windows ones do. best regards Bernd Stahlbock keywords: lock-up, wait_for_cmd_done timeout,transmit timeout, reset .... -- stahlbock@basysprint.de, http://www.basysprint.de basysPrint GmbH, Guelzer Str. 15, 19258 Boizenburg, Germany Tel.: ++49-38847-99-150, Fax:++49-38847-99-192 From becker@scyld.com Mon May 13 16:37:04 2002 From: becker@scyld.com (Donald Becker) Date: Mon May 13 15:37:04 2002 Subject: Re[2]: [eepro100] I have problem my intell 82559 card. In-Reply-To: Message-ID: On Fri, 3 May 2002, Petrov M.I. wrote: > Thanks for help me. .. > > What driver version? > > "eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n" > "eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin and others\n"; That's not my driver release. You should ask the last person to modify it why it's not working. Try http://www.scyld.com/network/eepro100.html > > What does > > eepro100-diag -aee > > report when the interface isn't working? ... > eepro100-diag.c:v2.07 12/28/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xd400. ... > EEPROM contents, size 64x16: > Intel EtherExpress Pro 10/100 EEPROM contents: ... > 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. Follow these directions. -- 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 kallol@efi.com Thu May 16 16:14:01 2002 From: kallol@efi.com (Kallol Biswas) Date: Thu May 16 15:14:01 2002 Subject: [eepro100] The decision making is getting delayed too long due gaps in understanding. Let us finalize the decision on Friday. Basuda will discuss the profit sharing and compensation issues. There is potential of getting consulting business in the area of ASIC design related to storage area network technology. For consulting work it will benetif_stop_queue() References: Message-ID: <3CE2DB89.38EF3EC@efi.com> Hi, Why do we need to use netif_[stop|start]_queue() routine in the nic driver? It is ok to lose packets. The upper layer takes care of resending it, right? Kallol From Matthew.Miller@sw.vccs.edu Thu May 16 16:25:27 2002 From: Matthew.Miller@sw.vccs.edu (Matthew Miller) Date: Thu May 16 15:25:27 2002 Subject: [eepro100] EE Pro 10/100 network drop outs using e100. Message-ID: <20020516143804.A2122@sw.vccs.edu> --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I have a Dell Poweredge 500SC server with an integrated eepro100 NIC. I'm running linux kernel 2.4.18 and while using the eepro100 driver I was experencing losses of network connectivity. After some searching and reading, the information I found seemed to suggest that using Intel's e100 driver would correct things. I thought that things were OK until yesterday. When all my remote display X apps disappeared :( Looking through the syslog shows that this was not a one time occurrence: May 9 12:45:53 roland kernel: e100: eth0 NIC Link is Down May 9 12:46:29 roland kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex May 15 16:24:39 roland kernel: e100: eth0 NIC Link is Down May 15 16:24:41 roland kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex May 15 16:24:57 roland kernel: e100: eth0 NIC Link is Down May 15 16:25:01 roland kernel: e100: eth0 NIC Link is Up 100 Mbps Full duplex 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. After looking through the archives for this list I've found no clues. I hope that someone can help! I've attached the output of dmesg and lspci, if any further information would be helpful just let me know. Thank you, Matthew -- Matthew Miller SVCC College Bound, Technology Coordinator --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.txt" Linux version 2.4.18 (root@roland) (gcc version 2.95.3 20010315 (release)) #3 Thu Mar 28 13:44:25 EST 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001ffffc00 (ACPI data) BIOS-e820: 000000001ffffc00 - 0000000020000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) found SMP MP-table at 000fe710 hm, page 000fe000 reserved twice. hm, page 000ff000 reserved twice. hm, page 000f0000 reserved twice. On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: PE 010B APIC at: 0xFEE00000 Processor #0 Pentium(tm) Pro APIC version 17 I/O APIC #1 Version 17 at 0xFEC00000. I/O APIC #2 Version 17 at 0xFEC01000. Processors: 1 Kernel command line: BOOT_IMAGE=Linux ro root=301 idebus=66 ide0=dma ide0=autotune ide_setup: idebus=66 ide_setup: ide0=dma ide_setup: ide0=autotune Initializing CPU#0 Detected 997.497 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1992.29 BogoMIPS Memory: 513760k/524224k available (1050k kernel code, 10080k reserved, 348k data, 228k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 CPU: Common caps: 0383fbff 00000000 00000000 00000000 CPU: Intel Pentium III (Coppermine) stepping 0a Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 ENABLING IO-APIC IRQs Setting 1 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 1 ... ok. Setting 2 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 1-0, 1-2, 1-11, 1-13, 2-5, 2-6, 2-9 not connected. ..TIMER: vector=0x31 pin1=-1 pin2=0 ...trying to set up timer (IRQ0) through the 8259A ... ..... (found pin 0) ...works. number of MP IRQ sources: 38. number of IO-APIC #1 registers: 16. number of IO-APIC #2 registers: 16. testing the IO APIC....................... IO APIC #1...... .... register #00: 01000000 ....... : physical APIC id: 01 .... register #01: 000F0011 ....... : max redirection entries: 000F ....... : PRQ implemented: 0 ....... : IO APIC version: 0011 .... register #02: 00000000 ....... : arbitration: 00 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 001 01 0 0 0 0 0 1 1 31 01 001 01 0 0 0 0 0 1 1 39 02 000 00 1 0 0 0 0 0 0 00 03 001 01 0 0 0 0 0 1 1 41 04 001 01 0 0 0 0 0 1 1 49 05 001 01 0 0 0 0 0 1 1 51 06 001 01 0 0 0 0 0 1 1 59 07 001 01 0 0 0 0 0 1 1 61 08 001 01 0 0 0 0 0 1 1 69 09 001 01 0 0 0 0 0 1 1 71 0a 001 01 1 1 0 1 0 1 1 79 0b 000 00 1 0 0 0 0 0 0 00 0c 001 01 0 0 0 0 0 1 1 81 0d 000 00 1 0 0 0 0 0 0 00 0e 001 01 0 0 0 0 0 1 1 89 0f 001 01 0 0 0 0 0 1 1 91 IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 .... register #01: 000F0011 ....... : max redirection entries: 000F ....... : PRQ implemented: 0 ....... : IO APIC version: 0011 .... register #02: 0C000000 ....... : arbitration: 0C .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 001 01 1 1 0 1 0 1 1 99 01 001 01 1 1 0 1 0 1 1 A1 02 001 01 1 1 0 1 0 1 1 A9 03 001 01 1 1 0 1 0 1 1 B1 04 001 01 1 1 0 1 0 1 1 B9 05 000 00 1 0 0 0 0 0 0 00 06 000 00 1 0 0 0 0 0 0 00 07 001 01 1 1 0 1 0 1 1 C1 08 001 01 1 1 0 1 0 1 1 C9 09 000 00 1 0 0 0 0 0 0 00 0a 001 01 1 1 0 1 0 1 1 D1 0b 001 01 1 1 0 1 0 1 1 D9 0c 001 01 1 1 0 1 0 1 1 E1 0d 001 01 1 1 0 1 0 1 1 E9 0e 001 01 1 1 0 1 0 1 1 32 0f 001 01 1 1 0 1 0 1 1 3A IRQ to pin mappings: IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ10 -> 0:10 IRQ12 -> 0:12 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 1:0 IRQ17 -> 1:1 IRQ18 -> 1:2 IRQ19 -> 1:3 IRQ20 -> 1:4 IRQ23 -> 1:7 IRQ24 -> 1:8 IRQ26 -> 1:10 IRQ27 -> 1:11 IRQ28 -> 1:12 IRQ29 -> 1:13 IRQ30 -> 1:14 IRQ31 -> 1:15 .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 997.4296 MHz. ..... host bus clock speed is 132.9904 MHz. cpu: 0, clocks: 1329904, slice: 664952 CPU0 PCI: PCI BIOS revision 2.10 entry at 0xfc82e, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Discovered primary peer bus 01 [IRQ] PCI: Using IRQ router ServerWorks [1166/0201] at 00:0f.0 PCI->APIC IRQ transform: (B0,I2,P0) -> 20 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd pty: 1024 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A block: 128 slots per queue, batch=32 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 66MHz system bus speed for PIO modes ServerWorks CSB5: IDE controller on PCI bus 00 dev 79 ServerWorks CSB5: chipset revision 146 ServerWorks CSB5: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x08b0-0x08b7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x08b8-0x08bf, BIOS settings: hdc:DMA, hdd:DMA hda: IC35L020AVER07-0, ATA DISK drive hdb: IC35L020AVER07-0, ATA DISK drive hdc: SAMSUNG CD-ROM SC-148C, ATAPI CD/DVD-ROM drive hdd: Seagate STT20000A, ATAPI TAPE drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 39062500 sectors (20000 MB) w/1916KiB Cache, CHS=2431/255/63 hdb: 39062500 sectors (20000 MB) w/1916KiB Cache, CHS=2431/255/63 hdc: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 hda3 hda4 hdb: hdb1 hdb2 Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: no supported devices found. [drm] Initialized tdfx 1.0.0 20010216 on minor 0 [drm] Initialized radeon 1.1.1 20010405 on minor 1 SCSI subsystem driver Revision: 1.00 request_module[scsi_hostadapter]: Root fs not mounted Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. ds: no socket drivers loaded! VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 228k freed Adding Swap: 514072k swap-space (priority -1) Adding Swap: 514040k swap-space (priority -2) parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected Intel(R) PRO/100 Fast Ethernet Adapter - Loadable driver, ver 1.6.29 Copyright (c) 2001 Intel Corporation eth0: Intel(R) 8255x-based Ethernet Adapter Using specified speed/duplex mode of 4. Mem:0xfe102000 IRQ:20 Speed:100 Mbps Dx:Full Hardware receive checksums enabled scsi0 : SCSI host adapter emulation for IDE ATAPI devices Vendor: Seagate Model: STT20000A Rev: 8A51 Type: Sequential-Access ANSI SCSI revision: 02 st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0 hdd: DMA disabled st0: Mode 0 options: buffer writes: 0, async writes: 0, read ahead: 0 st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0, st0: defs for wr: 0, no block limits: 1, partitions: 0, s2 log: 0 st0: sysv: 0 nowait: 0 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pci.txt" 00:00.0 Host bridge: Relience Computer CNB20HE (rev 06) 00:00.1 Host bridge: Relience Computer CNB20HE (rev 06) 00:02.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 00:0b.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:0f.0 ISA bridge: Relience Computer: Unknown device 0201 (rev 92) 00:0f.1 IDE interface: Relience Computer: Unknown device 0212 (rev 92) 00:0f.2 USB Controller: Relience Computer: Unknown device 0220 (rev 05) 00:0f.3 Host bridge: Relience Computer: Unknown device 0230 --YZ5djTAD1cGYuMQK-- From kallol@efi.com Fri May 17 00:38:01 2002 From: kallol@efi.com (Kallol Biswas) Date: Thu May 16 23:38:01 2002 Subject: [eepro100] The decision making is getting delayed too long due to gaps in understanding. Let us finalize the decision onFriday. Basuda will discuss the profit sharing andcompensation issues. There is potential of gettingconsulting business in the area of ASIC design relatedto storage area network technology. For consultingwork it will benetif_stop_queue() References: <3CE2DB89.38EF3EC@efi.com> Message-ID: <3CE40EBC.79F6ABB@efi.com> I apologize for the subject. I don't know how a part of my mail to a person got copied as the subject. The subject is only "benetif_stop_queue()" Kallol Biswas wrote: > Hi, > Why do we need to use netif_[stop|start]_queue() routine in the nic > driver? It is ok to lose packets. The upper layer takes care of resending it, > right? > > Kallol > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 From gdalevich@hotmail.com Fri May 17 00:38:51 2002 From: gdalevich@hotmail.com (Alexander Gdalevich) Date: Thu May 16 23:38:51 2002 Subject: [eepro100] The decision making is getting delayed too long due gaps in understanding. Let us finalize the decision on Friday. Basuda will discuss the profit sharing and compensation issues. There is potential of getting consulting business in the area of ASIC design related to storage area network technology. For consulting work it will benetif_stop_queue() Message-ID: The problem is that it will not resend UDP messages. Also, TCP packets will be resend only after an ack was received for the previous one, or, worse yet, after a timeout. >From: Kallol Biswas >CC: eepro100@scyld.com >Subject: [eepro100] The decision making is getting delayed too long due >gaps in understanding. Let us finalize the decision on Friday. Basuda will >discuss the profit sharing and compensation issues. There is potential of >getting consulting business in the area of ASIC design related to storage >area network technology. For consulting work it will benetif_stop_queue() >Date: Wed, 15 May 2002 15:04:57 -0700 > >Hi, > Why do we need to use netif_[stop|start]_queue() routine in the nic >driver? It is ok to lose packets. The upper layer takes care of resending >it, >right? > >Kallol > >_______________________________________________ >eepro100 mailing list >eepro100@scyld.com >http://www.scyld.com/mailman/listinfo/eepro100 _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From o.darchuk@wucb.lviv.net Fri May 17 12:28:36 2002 From: o.darchuk@wucb.lviv.net (Oleksandr Darchuk) Date: Fri May 17 11:28:36 2002 Subject: [eepro100] network adapter teaming and eepro100 driver Message-ID: <200205171323.QAA14714@mover.WUCB.Lviv.net> Hello I'm using Compaq DL 380 servers with onboard Intel NIC. I use RedHat 7.1 and kernel 2.4.17. and driver eepro100 for NIC. Question: are there any options to build network adapter teaming with eepro100 To be exect I mean somith like described in this URL, but on LInux. http://www.compaq.com/products/servers/networking/teaming.html Thanx a lot. From larrysmith19002@yahoo.com Sat May 18 14:05:00 2002 From: larrysmith19002@yahoo.com (larry smith) Date: Sat May 18 13:05:00 2002 Subject: [eepro100] URGENT AND CONFIDENTIAL Message-ID: <20020518170433.11047.qmail@web21507.mail.yahoo.com> Mr.Larry Smith, 3/5 RIDER HAGGARD CLOSE, JO, BORG SOUTH AFRICA. Email; larrysmith19002@yahoo.com [TRANSFER OF $ 152,000.000.00 USA] [ONE HUNDRED AND FIFTY TWO MILLION DOLLARS ] HELLO, 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.Larry Smith, 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 Dollars 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; larrysmith19002@yahoo.com Tel nos; 882-164-6651141. Fax nos; 874-762-727949. yours, Larry Smith. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From dave_worthy@hp.com Mon May 20 23:15:00 2002 From: dave_worthy@hp.com (Dave Worthy) Date: Mon May 20 22:15:00 2002 Subject: [eepro100] Compiling pci-scan and merging into source tree Message-ID: <3CE9AD64.C2587E3A@hp.com> Hello all, I'm trying to add the pci-scan.c source into my kernel (2.4.14) tree such that a 'make modules' will pick up not only the eepro100, but pci-scan also. Then the 'make modules_install' would automatically pick up this module and the dependency. I saw some directions at this site: http://www.scyld.com/network/updates.html#single under the heading "Installing Individual Driversl"....and this all seems to work but needing to remember to manually move pci-scan may be difficult to remember when/if recompiling this kernel....especially if someone else has to do it. A nice big README should work, but looking for the smoother answer. [make modules output] make -C net modules make[2]: Entering directory `/usr/src/linux-2.4.14/drivers/net' gcc -D__KERNEL__ -I/usr/src/linux-2.4.14/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.14/include/linux/modversions.h -c -o eepro100.o eepro100.c make[2]: Leaving directory `/usr/src/linux-2.4.14/drivers/net' [make modules_install] mkdir -p pcmcia; \ find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.14acenic; fi depmod: *** Unresolved symbols in /lib/modules/2.4.14acenic/kernel/drivers/net/eepro100.o depmod: acpi_set_pwr_state depmod: pci_drv_unregister depmod: pci_drv_register make: *** [_modinst_post] Error 1 [ ls -al drivers/net/eepro100* drivers/net/pci-scan* ] [ note the timestamps for .o files aren't the same] -rw-r--r-- 1 root root 67041 May 17 21:24 drivers/net/eepro100.c -rw-r--r-- 1 root root 21664 May 20 22:02 drivers/net/eepro100.o -rw-r--r-- 1 root root 17856 May 20 10:38 drivers/net/pci-scan.c -rw-r--r-- 1 root root 2990 May 20 10:38 drivers/net/pci-scan.h -rw-r--r-- 1 root root 6532 May 20 10:50 drivers/net/pci-scan.o I'm guessing something in the Makefile needs tweaked, but that all looks greek to me right now. If this is something easy I've overlooked, apologies in advance. Thanks Dave Worthy From dave_worthy@hp.com Fri May 24 00:13:00 2002 From: dave_worthy@hp.com (Dave Worthy) Date: Thu May 23 23:13:00 2002 Subject: [eepro100] Compiling pci-scan and merging into source tree Message-ID: <3CEDAF81.19AFFB5A@hp.com> I found that if you do the following, the pci-scan will compile in to a 'make modules' as well as show up in a 'make menuconfig'......it won't allow you to toggle the pci-scan, but will show it and more importantly compile it: *NOTE* very important that the variables for PCI_SCAN has an "_" and not a dash "-". This will result in an #undef warning from autoconf.h 1.) in /usr/src/linux/drivers/net/Makefile, After this line: obj-$(CONFIG_EEPRO100) += eepro100.o Add this line here: obj-$(CONFIG_PCI_SCAN) += pci-scan.o 2.) in /usr/src/linux/drivers/net/Config.in, After this line: dep_tristate ' EtherExpressPro/100 support' CONFIG_EEPRO100 $CONFIG_PCI Add this line: dep_tristate ' PCI Scan Hack for eepro100' CONFIG_PCI_SCAN $CONFIG_EEPRO100 $CONFIG_PCI (all one line) This Makes pci-scan dependent on pci and the eepro100 being configured. 3.) Look at your current .config file: #:) grep -i pci_scan .config #:) grep -i eepro .config CONFIG_EEPRO100=m Only eepro100 is a module: 4.) cd /usr/src/linux and run 'make menuconfig': Select 'Network Device Support' Select 'Ethernet (10 or 100 Mbit)' Page down to where 'EtherExpressPro/100 support' is, select it as a module and you should see "PCI Scan Hack for eepro100" Select the PCI_SCAN 5.) Save the .config file upon exit and do a grep to see if the .config file now knows of pci-scan: #:) grep -i eepro .config CONFIG_EEPRO100=m #:) grep -i pci_scan .config CONFIG_PCI_SCAN=m 6.) make dep; make clean; make modules; make modules_install 7.) note that the eepro100 and pci-scan modules show up in the /lib/modules//kernel/drivers/net directory fyi... I've compiled the modules this way and manually just in case it is botched up with this hack and am testing it....it booted and loaded fine. Time will be the indicator...... Any feedback would be great. Thanks! From cath_k_wiwa@excite.com Mon May 27 09:26:00 2002 From: cath_k_wiwa@excite.com (PASCHAL DON-PEDRO) Date: Mon May 27 08:26:00 2002 Subject: [eepro100] A REQUEST FOR ASSISTANCE. Message-ID: <200205271225.g4RCPOO27664@blueraja.scyld.com> Mrs. Catherine ken Saro Wiwa Ogoni Tribe Nigeria E-mail:cath_k_wiwa@excite.com A REQUEST FOR ASSISTANCE. My name is Mrs. Catherine Ken Saro Wiwa, I hail from Ogoni, a minority but an oil rich tribe of the eastern Nigeria (west Africa). You may have been aware that my husband, Mr. Ken Saro Wiwa,renowned poet was recently hanged among eight others, by the tyrannical military led government of Nigeria. Their offence lied only on their resolve to fight without arms, for the right of the ogoni peoples whose land and natural resources have been subjected to untold pollution and other serious environmental degradations as a result of oil-drilling activities by the oil companies. Government refused to pay any meaningful financial compensation to the people of ogoni hence the armless struggle by my late husband and his elite compatriots leading to their cruel demise. The attorney to my late husband called a fortnight ago and intimated me that some money is due from an association of oil companies to my late husband, in the sum of Eighteen million united state dollars (US$18M). He has also suggested that I should make an arrangement for a bank account out side Nigeria where this money will be transferred. This is to avoid any possibility of confiscation by the ravaged, thirsty government of Nigeria. This is where I solicit for your assistance. I shall be please to give you 15% of the total sum if you would offer me your bank account for this purpose,10% of it will be donated to some organization as my late husband has willed, while my children and I would utilize the rest to continue our life out side Nigeria. Please be kind hearted enough to contact my family attorney's Barr. Mikael Ihetu on his email address: mikael_ihetu@law.com and send him your private contacts for easy and more confidential communication. I count on your mercy and understanding and wait for your early response. Yours in need, Mrs. Catherine K. Saro Wiwa My Alternative email:ck_wiwa@yahoo.com From areinhol@le-gobw.de Wed May 29 02:55:01 2002 From: areinhol@le-gobw.de (Axel Reinhold) Date: Wed May 29 01:55:01 2002 Subject: [eepro100] netdrivers.tgz for 2.2.21 Message-ID: <200205290550.g4T5o8d01354@l0p.le-gobw.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, latest version of netdrivers.tgz do not work with new Linux 2.2.21. After loading the modules -> panic. Will there be a fix soon? I stuck with 2.2.20 (including the zlib security bug) cause I need up-to-date netdrivers.tgz drivers. Regards Axel Reinhold - -- +----------------------------------------------------------+ | Le-go Bekleidungswerke | Fon: +49-9281/750-290 | | Axel Reinhold, EDV | Fax: +49-9281/750-270 | | Am Wiesengrund 20 | eMail: Axel.Reinhold@Le-goBW.de | | 95032 Hof | WWW: http://www.le-gobw.de | +----------------------------------------------------------+ | Bitte um Nur-Text-Mails - Office- und .EXE-Anhaenge | | oeffne ich grundsaetzlich nicht. | +----------------------------------------------------------+ BEGIN:VCARD VERSION:2.1 N:Reinhold;Axel FN:Axel Reinhold ORG:Le-go Bekleidungswerke GmbH ADR:;;Am Wiesengrund 20;Hof;;95032;Germany TEL;WORK:+49-9281/750-290 TEL;FAX:+49-9281/750-270 TEL;CELL:+49-170/2934048 EMAIL:Axel.Reinhold@Le-goBW.de END:VCARD -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPPRsEA127r+uSGS+EQKcOQCdGsUrfcar9dcbxqCFOFb4Ew6sroUAn1Vr sORIA1KzbqqkgIk3+UMr+P7i =PJhz -----END PGP SIGNATURE----- From lomesh.agarwal@intel.com Thu May 30 16:18:01 2002 From: lomesh.agarwal@intel.com (Agarwal, Lomesh) Date: Thu May 30 15:18:01 2002 Subject: [eepro100] 82559ER command reference Message-ID: <01BDB7EEF8D4D3119D95009027AE999512F66027@fmsmsx33.fm.intel.com> I was trying to understand the 82559 driver. Can someone point me to the document which has all the "command unit command" and "receive unit command". I downloaded 82559er datasheet from Intel website but that doesn't have this info. Thanks, Lomesh From lomesh.agarwal@intel.com Thu May 30 17:54:00 2002 From: lomesh.agarwal@intel.com (Agarwal, Lomesh) Date: Thu May 30 16:54:00 2002 Subject: [eepro100] Problem with 82559 driver Message-ID: <01BDB7EEF8D4D3119D95009027AE999512F6602B@fmsmsx33.fm.intel.com> Hi, I took 82559 driver for IQ80310 RedBoot and ported it to my platform. I82559_init passes successfully and I can find the device and its BARs are initialized properly. But the problem is that I don't see any data packet coming out on wire (I hooked the NIC to IXIA which is a packet analyzer) when I try to ping a host. I am using static IP address. Another thing is that my board has 82559ER in place of 82559. When I do a ping TxMachine function is called and it starts a tx operation. Then I see TxMachine being called again. This time it goes to tx_in_progress block and there I find SCB status as 0x10 and it assumes that CU is idle. But I don't see any packet coming out. Can someone give me some hint as to what may be possibly wrong? Also can someone point me to the document which has all the "command unit command" and "receive unit command". I downloaded 82559er datasheet from Intel website but that doesn't have this info. Thanks, Lomesh From sherbold@rcnets.com Fri May 31 15:47:01 2002 From: sherbold@rcnets.com (Herbold, Steve) Date: Fri May 31 14:47:01 2002 Subject: [eepro100] RE: 82559ER command reference Message-ID: We are developing/modifying drivers for this family of Intel parts, and have found the best (only?) documentation is through an Intel 'Secret/Confidential' document: 10/100 MBIT ETHERNET FAMILY SOFTWARE TECHNICAL REFERENCE MANUAL Rev 1.1 Ref No OR-1861 You have to go through your Intel rep and sign off some NDAs to receive it. It probably contains the information you are looking for versus the datasheet which only vaguely specifies necessary information to program and use the part. From: "Agarwal, Lomesh" To: "'eepro100@scyld.com'" Date: Thu, 30 May 2002 12:17:16 -0700 Subject: [eepro100] 82559ER command reference I was trying to understand the 82559 driver. Can someone point me to the document which has all the "command unit command" and "receive unit command". I downloaded 82559er datasheet from Intel website but that doesn't have this info. Thanks, Lomesh From sherbold@rcnets.com Fri May 31 16:06:00 2002 From: sherbold@rcnets.com (Herbold, Steve) Date: Fri May 31 15:06:00 2002 Subject: [eepro100] RE: 82559 driver & no packets in/out Message-ID: Possibly similar problem encountered when we were porting driver code to PPC405 for PPCBoot. Our setup did not have a serial eeprom to configure part, this was done through sw (including mac addr). Driver reset part and tried to send packets relying on many default register settings. Found that one bit in a configuration register defaults to 0, but needs to be 1 for '559. It is bit 0 of byte 8 (believe this is the same data for configuration eeprom) which is called 503#/MII. Symptoms were part would process tx packets without a complaint but nothing was ever seen on the interface (link was ok). Finally dumped statistic registers, and had indication that there was failed tx due to loss of carrier sense (?). Finally had to just verify all registers were being configured properly which was where I found this bit needing to be configured. ------------------------------------------------------- From: "Agarwal, Lomesh" To: "'eepro100@scyld.com'" , "ecos-discuss (E-Mail)" Date: Thu, 30 May 2002 13:53:15 -0700 Subject: [eepro100] Problem with 82559 driver Hi, I took 82559 driver for IQ80310 RedBoot and ported it to my platform. I82559_init passes successfully and I can find the device and its BARs are initialized properly. But the problem is that I don't see any data packet coming out on wire (I hooked the NIC to IXIA which is a packet analyzer) when I try to ping a host. I am using static IP address. Another thing is that my board has 82559ER in place of 82559. When I do a ping TxMachine function is called and it starts a tx operation. Then I see TxMachine being called again. This time it goes to tx_in_progress block and there I find SCB status as 0x10 and it assumes that CU is idle. But I don't see any packet coming out. Can someone give me some hint as to what may be possibly wrong? Also can someone point me to the document which has all the "command unit command" and "receive unit command". I downloaded 82559er datasheet from Intel website but that doesn't have this info. Thanks, Lomesh