Unserviced interrupts due to Flow Control Paused status = bit

From curtisb@citrine.workspot.com Wed Mar 1 20:46:53 2000 Date: Wed Mar 1 20:46:53 2000 From: Curtis M. Brune curtisb@citrine.workspot.com Subject: Intel Pro 100+ Dual Port Server Adapter Does anyone have any success stories with this NIC? Cheers, Curt -- WorkSpot, Inc. http://www.workspot.com Phone 650-566-8109 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From dts@senie.com Wed Mar 1 23:11:44 2000 Date: Wed Mar 1 23:11:44 2000 From: Daniel Senie dts@senie.com Subject: Intel Pro 100+ Dual Port Server Adapter "Curtis M. Brune" wrote: > > Does anyone have any success stories with this NIC? I have two of them deployed. Both worked with the driver shipped stock in RedHat 6.1, and both work quite well with the Intel-written driver. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From RKrawl@microtest.com Wed Mar 1 23:32:16 2000 Date: Wed Mar 1 23:32:16 2000 From: Krawl, Roeland RKrawl@microtest.com Subject: Unserviced interrupts due to Flow Control Paused status bit This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8400.312772E0 Content-Type: text/plain A possible flaw in the eepro100.c driver (version 1.09l 8/7/99) is causing Linux to hang due to unserviced NIC interrupts. Just after the bootd daemon issues the messages "Starting Network" and "Starting DHCP", the prepareInterface() routine in bootd/if.c will issue a SIOCSIFFLAGS ioctl call (from the prepareInterface routine) which NEVER COMPLETES. The Linux box hangs as a result of unserviced NIC interrupts. Apparently, the speedo_interrupt() routine does not properly service the interrupt when the System Control Block Status Word contains 0x150. According to the 82559ER datasheet, this status means that the Flow Control Paused bit is set. ( The datasheet provides no information about how to interpret the transmitter and receiver status bits). Does a value of 0x400 written to the SCB command word acknowledge the interrupt? I have noticed that the symptom will go away when various kernel modules grow in size as a result of added code. I would prefer to fix the problem rather than have it reappear in future kernel rebuilds. I suspect that an uninitialized variable or a partially initialized 82559 is causing this symptom. The 82559ER datasheets are not acceptable for writing a driver. I am trying to obtain suitable documentation from Intel but so far have had no luck. I am convinced that the info is not on the Intel website and I am hoping that an open tech support incident with Intel will eventually prove fruitful. Obviously, Donald Becker found such a document. Does anyone know an efficient way to obtain the programmer's manual from Intel? Your ideas or suggestions are welcome. Thanks, Roeland Krawl ------_=_NextPart_001_01BF8400.312772E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Unserviced interrupts due to Flow Control Paused status = bit

A possible flaw in the eepro100.c = driver (version 1.09l 8/7/99) is causing Linux to hang due to = unserviced NIC interrupts.

Just after the bootd daemon issues the = messages "Starting Network" and "Starting = DHCP", the prepareInterface() routine in bootd/if.c will = issue a SIOCSIFFLAGS ioctl call (from the prepareInterface routine) = which NEVER COMPLETES. The Linux box hangs as a result of unserviced = NIC interrupts.

Apparently, the speedo_interrupt() = routine does not properly service the interrupt when the System Control = Block Status Word contains 0x150. According to the 82559ER datasheet, = this status means that the Flow Control Paused bit is set. ( The = datasheet provides no information about how to interpret the = transmitter and receiver status bits). Does a value of 0x400 written to = the SCB command word acknowledge the interrupt?

I have noticed that the symptom will = go away when various kernel modules grow in size as a result of added = code.

I would prefer to fix the problem = rather than have it reappear in future kernel rebuilds. I suspect that = an uninitialized variable or a partially initialized 82559 is causing = this symptom.

The 82559ER datasheets are not = acceptable for writing a driver. I am trying to obtain suitable = documentation from Intel but so far have had no luck. I am convinced = that the info is not on the Intel website and I am hoping that an open = tech support incident with Intel will eventually prove = fruitful.

Obviously, Donald Becker found such a = document. Does anyone know an efficient way to obtain the programmer's = manual from Intel?

Your ideas or suggestions are = welcome.

Thanks,
Roeland Krawl

------_=_NextPart_001_01BF8400.312772E0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From black@real.com Thu Mar 2 00:47:56 2000 Date: Thu Mar 2 00:47:56 2000 From: Jerry Glomph Black black@real.com Subject: Intel Pro 100+ Dual Port Server Adapter We have used it; it looks to Linux like two separate cards. No problems at all. On Wed, 1 Mar 2000, Curtis M. Brune wrote: > Does anyone have any success stories with this NIC? > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Thu Mar 2 02:00:07 2000 Date: Thu Mar 2 02:00:07 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: Problem with hang-up on the Intel card Hello, On Tue, Feb 29, 2000 at 11:08:25PM +0100, Alain NINANE wrote: > Folks, > I'm currently modifying Donald's driver to play with my own buffer > management - basically, the skbuff objects have been replaced by private > structures also known, by memory mapping, at the user level. > > As in the original driver, my private structures are linked to the RxFD > rx_ringp in the speedo_private data structure. In my software, the > receiver structures are statically allocated. That means that in some > situations, I may have the rx_ringp structures empty with no more RxFD > descriptors available for the NIC. In this case however, the driver try > to restart the receiver with the RxResumeNoResources and RxStart > commands. But this is is unsuccessful ... Do you have any hints ? The first note: you can't pass the last skb from the ring to the upper layers because it contains the "link" field. There are also certain problems when the card reports "no resource" or "no RX buffers" conditions. Sometimes the hardware do it preliminary when there are still some buffers. In this case the receiver should always be restarted. For more details you may wish to look at the modified driver in 2.2.15pre12 kernel. Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From thebs@theseus.com Thu Mar 2 10:08:50 2000 Date: Thu Mar 2 10:08:50 2000 From: Bryan -TheBS- Smith thebs@theseus.com Subject: I need more comments/suggestions -- Re: Intel Pro 100+ Dual Port Server Adapter On Thu, 02 Mar 2000, Jerry Glomph Black wrote: > We have used it; it looks to Linux like two separate cards. > No problems at all. Is that the i82558 or i82559 chip? I am good friends with Mark Matthews (lives ~10 miles away) and was over hacking with him last night. He guess it was the i82558 chip before I even told him anything. His comment was that "Intel does not document it well, which results in Intel not telling people things about the chip until its a well-known problem." Did Intel fix a bit between the 82558 and 82559? I thought the later was just for wake on LAN (WOL) support? E.g.: i82556: EEPro/100[A] (these guys suck, unsupported in Linux) i82557: EEPro/100B (I have these, excellent cards IMHO!) i82558: EEPro/100+ (First experience, a bad one too) i82559: EEPro/100+ WOL (Have several, no problems) The Becker eepro100 driver, again, supports the 82557, 82558 and 82559. The Intel e100 driver supports only (select?) 82558 and (all?) 82559 cards (no i82557). No one supports the older i82556 (which I find has trouble with PCI 2.1/2.2 systems). I was, more or less, wondering if anyone had tried the official Intel e100 driver and compared it to Becker's established eepro100 driver. The point may be moot anyway, the Linksys LNE100TX (Tulip variant) I have in my server now seems to be working fine. Just concerned that, compared to the EEPro/100s, it may be: A. More CPU intensive on high loads (common on my network) B. Less capable throughput (possibly combined with A?) Comments? Suggestions? Thanx in advance ... -- Bryan J. Smith Theseus Logic P.S. Comments, suggestions on Gigabit cards??? I was looking at the low-cost NetGear 620 (~$300) and the EEPro/1000 (~$600). My switches are Intel EEStack 510Ts, and I would be adding the SX module to them (~$700). P.S.S. I usually RTFM, but can you use that dual-port card on the same subnet, even same IP? The EEStack 510T supports 802.1d (tree spanning protocol) so I was wondering if I could combine such a card (or two single port ones) to increase bandwidth (let alone redundancy)? -- Bryan "TheBS" Smith -- Engineer, IT Professional and Hacker E-mail: mailto:thebs@theseus.com,b.j.smith@ieee.org Disclaimer: http://www.SmithConcepts.com/legal.html ************************************************************* TheBS ... Serving E-mail filters to /dev/null since 1989 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From thebs@theseus.com Thu Mar 2 13:27:08 2000 Date: Thu Mar 2 13:27:08 2000 From: Bryan -TheBS- Smith thebs@theseus.com Subject: I need more comments/suggestions -- Re: Intel Pro 100+ Dual Port Server Adapter On Thu, 02 Mar 2000, Jerry Glomph Black wrote: > The dual-Intel card we have has the 82557. I've never had a problem with the i82557 (used many), nor the i82559 (but only have 2 in use). But this was my first i82558. Bad things man, bad things! > As I said before, indistinguishable from 2 separate cards Figured as such. Just wondering how you are using them? -- TheBS P.S. Does it have a PCI-PCI bridge? I assume not because they seem to be on the same PCI bus: > Bus 2, device 5, function 0: > Bus 2, device 4, function 0: P.S.S. I have not read the ettique/FAQ of this list (yes, I know, am I bad!). Is it proper to post responses back to the list? Or should I be taking them private??? -- Bryan "TheBS" Smith -- Engineer, IT Professional and Hacker E-mail: mailto:thebs@theseus.com,b.j.smith@ieee.org Disclaimer: http://www.SmithConcepts.com/legal.html ************************************************************* TheBS ... Serving E-mail filters to /dev/null since 1989 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From dts@senie.com Thu Mar 2 16:41:52 2000 Date: Thu Mar 2 16:41:52 2000 From: Daniel Senie dts@senie.com Subject: I need more comments/suggestions -- Re: Intel Pro 100+ Dual Port Server Adapter Bryan -TheBS- Smith wrote: > > On Thu, 02 Mar 2000, Jerry Glomph Black wrote: > > The dual-Intel card we have has the 82557. > > I've never had a problem with the i82557 (used many), nor the > i82559 (but only have 2 in use). But this was my first i82558. > Bad things man, bad things! The present dual cards shipping from Intel have 82558 chips. > > > As I said before, indistinguishable from 2 separate cards > > Figured as such. Just wondering how you are using them? > > -- TheBS > > P.S. Does it have a PCI-PCI bridge? I assume not because they > seem to be on the same PCI bus: > > Bus 2, device 5, function 0: > > Bus 2, device 4, function 0: The card DOES have a PCI-PCI bridge, 21xxx series chip. The just-released Linux driver available on the Intel website works very well with these cards and others. Folks trying to figure out how to talk to these chips will probably find your answers in the source code Intel released. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From cconvey@home.com Thu Mar 2 21:19:11 2000 Date: Thu Mar 2 21:19:11 2000 From: Christian Convey cconvey@home.com Subject: Build problems w/Mandrake 7.0 GPL Hello all, Newbie problem (I hope)... I've just installed Mandrake 7.0 GPL version, and am trying to build the file: ftp://cesdis.csfc.nasa.gov/pub/linux/drivers/test/eepro100.c The version string in the file begins with the text: "eepro100.c:v1.09t 9/29/99 Donald Becker I try to build it with the command: gcc -DMODVERSIONS -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -O6 -c driver.c When I try to build, I get tons of build errors. The beginning of the error output looks like the following. Has anyone seen this before, or can anyone recommend a way around it? Thanks for any help you can provide, Christian Convey In file included from /usr/include/linux/sched.h:20, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from eepro100.c:95: /usr/include/linux/smp.h:77: warning: `smp_num_cpus' redefined /usr/include/linux/modules-secure/i386_ksyms.ver:72: warning: this is the location of the previous definition /usr/include/linux/smp.h:83: warning: `smp_call_function' redefined /usr/include/linux/modules-secure/i386_ksyms.ver:98: warning: this is the location of the previous definition In file included from /usr/include/linux/sched.h:74, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from eepro100.c:95: /usr/include/asm/processor.h:96: warning: `cpu_data' redefined /usr/include/linux/modules-secure/i386_ksyms.ver:62: warning: this is the location of the previous definition In file included from /usr/include/linux/interrupt.h:51, from eepro100.c:96: /usr/include/asm/hardirq.h:23: warning: `synchronize_irq' redefined /usr/include/linux/modules-secure/i386_ksyms.ver:78: warning: this is the location of the previous definition In file included from /usr/include/linux/interrupt.h:52, from eepro100.c:96: /usr/include/asm/softirq.h:72: warning: `synchronize_bh' redefined /usr/include/linux/modules-secure/i386_ksyms.ver:80: warning: this is the location of the previous definition In file included from /usr/include/linux/string.h:37, from eepro100.c:91: ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From RKrawl@microtest.com Thu Mar 2 22:51:32 2000 Date: Thu Mar 2 22:51:32 2000 From: Krawl, Roeland RKrawl@microtest.com Subject: I need more comments/suggestions -- Re: Intel Pro 100+ Dual P ort Server Adapter This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF84C3.ADC85CA0 Content-Type: text/plain I can not find the "just-released Linux driver" on Intels website. I found drivers for many other OS'es but not for Linux. A URL to the Linux driver would be helpful. Thanks, Roeland Krawl Daniel Senie wrote: >> The just-released Linux driver available on the Intel website works very >> well with these cards and others. >> Folks trying to figure out how to talk >> to these chips will probably find your answers in the source code Intel >> released. ------_=_NextPart_001_01BF84C3.ADC85CA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I need more comments/suggestions -- Re: Intel Pro 100+ Dual = Port Server Adapter

I can not find the "just-released = Linux driver" on Intels website. I found drivers for many other = OS'es but not for Linux. A URL to the Linux driver would be = helpful.

Thanks,
Roeland Krawl

Daniel Senie wrote:
>> The just-released Linux = driver available on the Intel website works very

>> well with these cards and = others.=20
>> Folks trying to figure out = how to talk
>> to these chips will probably = find your answers in the source code Intel
>> released.

------_=_NextPart_001_01BF84C3.ADC85CA0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From warnes@biostat.washington.edu Fri Mar 3 00:09:11 2000 Date: Fri Mar 3 00:09:11 2000 From: Gregory R. Warnes warnes@biostat.washington.edu Subject: I need more comments/suggestions -- Re: Intel Pro 100+ Dual P ort Server Adapter http://support.intel.com/support/network/adapter/pro100/e100-1.0.0.htm On Thu, 2 Mar 2000, Krawl, Roeland wrote: KR>> I can not find the "just-released Linux driver" on Intels website. I KR>> found drivers for many other OS'es but not for Linux. A URL to the Linux KR>> driver would be helpful. KR>> KR>> Thanks, KR>> Roeland Krawl KR>> KR>> KR>> Daniel Senie wrote: KR>> >> The just-released Linux driver available on the Intel website KR>> works very KR>> >> well with these cards and others. KR>> >> Folks trying to figure out how to talk KR>> >> to these chips will probably find your answers in the source code Intel KR>> >> released. KR>> KR>> ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From dts@senie.com Fri Mar 3 00:42:03 2000 Date: Fri Mar 3 00:42:03 2000 From: Daniel Senie dts@senie.com Subject: I need more comments/suggestions -- Re: Intel Pro 100+ Dual Port Server Adapter > "Krawl, Roeland" wrote: > > I can not find the "just-released Linux driver" on Intels > website. I found drivers for many other OS'es but not for Linux. > A URL to the Linux driver would be helpful. Navigation: http://www.intel.com/ select support, drivers, networking, ethernet, single and dual port server adapters. And you'll see it. or, try: http://support.intel.com/support/network/adapter/pro100/pro100dp/software.htm and you'll see the Linux driver listed. One word of caution. If you use a box which runs an SMP kernel, recompile the driver before trying to use it. > Daniel Senie wrote: > >> The just-released Linux driver available on the Intel website > works very > > >> well with these cards and others. > >> Folks trying to figure out how to talk > >> to these chips will probably find your answers in the source code > Intel > >> released. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From llucius@tiny.net Fri Mar 3 01:35:07 2000 Date: Fri Mar 3 01:35:07 2000 From: Cy llucius@tiny.net Subject: I need more comments/suggestions -- Re: Intel Pro 100+ Dual Port Server Adapter This is a multi-part message in MIME format. ------=_NextPart_000_0001_01BF84A8.63C8F630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: I need more comments/suggestions -- Re: Intel Pro 100+ Dual Port Server AdapterIntel's Linux driver: http://support.intel.com/support/network/adapter/pro100/30504.htm -----Original Message----- From: owner-linux-eepro100@beowulf.org [mailto:owner-linux-eepro100@beowulf.org]On Behalf Of Krawl, Roeland Sent: Thursday, March 02, 2000 9:51 PM To: linux-eepro100@beowulf.gsfc.nasa.gov Subject: RE: I need more comments/suggestions -- Re: Intel Pro 100+ Dual Port Server Adapter I can not find the "just-released Linux driver" on Intels website. I found drivers for many other OS'es but not for Linux. A URL to the Linux driver would be helpful. Thanks, Roeland Krawl Daniel Senie wrote: >> The just-released Linux driver available on the Intel website works very >> well with these cards and others. >> Folks trying to figure out how to talk >> to these chips will probably find your answers in the source code Intel >> released. ------=_NextPart_000_0001_01BF84A8.63C8F630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I need more comments/suggestions -- Re: Intel Pro 100+ Dual = Port Server Adapter

Intel's Linux driver:

http://support.intel.com/support/network/adapter/pro100/30504.htm

-----Original Message-----
From:=20 owner-linux-eepro100@beowulf.org=20 [mailto:owner-linux-eepro100@beowulf.org]On Behalf Of Krawl,=20 Roeland
Sent: Thursday, March 02, 2000 9:51 PM
To: = linux-eepro100@beowulf.gsfc.nasa.gov
Subject: RE: I need = more=20 comments/suggestions -- Re: Intel Pro 100+ Dual Port Server=20 Adapter

I can not find the "just-released = Linux driver"=20 on Intels website. I found drivers for many other OS'es but not for = Linux. A=20 URL to the Linux driver would be helpful.

Thanks,
Roeland Krawl

Daniel Senie wrote:
>> The just-released Linux driver available on the = Intel=20 website works very

>> well with these cards and = others.=20
>> Folks trying to figure out = how to=20 talk
>> to these chips = will probably=20 find your answers in the source code Intel
>> released.

------=_NextPart_000_0001_01BF84A8.63C8F630-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jbkinsey@puc.edu Mon Mar 6 20:25:35 2000 Date: Mon Mar 6 20:25:35 2000 From: Jeffrey Kinsey jbkinsey@puc.edu Subject: Intel Pro/100+ Management Adapter Dear eepro100 people, I'm new to linux, and I can't get my network card working. I've got a intel Pro/100+ Management Adapter in my machine with a voodoo3 2000 PCI. When I boot up, I get a failed message for eth0 which reads "Delaying eth0 initialization". In my conf.modules file it has alias eth0 eepro100 I would kiss anyone who could help me out with my problem. Thanks, Jeffrey ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From sarahjames@home.com Mon Mar 6 21:51:28 2000 Date: Mon Mar 6 21:51:28 2000 From: Sarah James sarahjames@home.com Subject: Problems with Intel board in a high volume web site We have just installed two new servers in our web site. One is a page server and the other is a database server. The database server is connected through a eepro 100 to the pageserver. The pageserver has two eepro 100's - one to the internet and the second to the database server. We are using the drivers available in Debian Linux 2.2.14 Here are the boot up messages on the page server- (eth0 connects to the internet via a 10MB/s connection - eth1 is the connection to the database server at 100MB/s). eth0: Intel EtherExpress Pro 10/100 at 0xb800, 00:D0:B7:1F:F9:98, IRQ 15. Receiver lock-up bug exists -- enabling work-around. Board assembly 721383-008, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). eth1: Intel EtherExpress Pro 10/100 at 0xb400, 00:D0:B7:1F:F4:27, IRQ 10. Receiver lock-up bug exists -- enabling work-around. Board assembly 721383-008, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). Everything worked well during testing. When we placed them in service, everything was fine until the server load picked up. We started experiencing packet losses of between 20 and 30% combined between the gateway and our server. There are no problems between the database server and the page server. We did some experimenting - all the errors stopped if we moved the server to a different IP (with no traffic) - and started as soon as we moved it back again. Our ISP says its our network card. We think its their gateway can't handle the traffic... hmmm. Questions: 1) Is the driver in the debian build different from http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Any comments on the driver available directly from Intel? http://support.intel.com/support/network/adapter/pro100/e100-1.0.0.htm 2) any ideas on what is causing this? TIA ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From richard@iguana.co.nz Mon Mar 6 23:27:03 2000 Date: Mon Mar 6 23:27:03 2000 From: richard@iguana.co.nz richard@iguana.co.nz Subject: Problems with Intel board in a high volume web site > We have just installed two new servers in our web site. One is a page server > and the other is a database server. The database server is connected through > a eepro 100 to the pageserver. The pageserver has two eepro 100's - one to > the internet and the second to the database server. > > Everything worked well during testing. When we placed them in service, > everything was fine until the server load picked up. We started experiencing > packet losses of between 20 and 30% combined between the gateway and our > server. There are no problems between the database server and the page > server. We did some experimenting - all the errors stopped if we moved the > server to a different IP (with no traffic) - and started as soon as we moved > it back again. Our ISP says its our network card. We think its their gateway > can't handle the traffic... hmmm. > > Questions: > 1) Is the driver in the debian build different from > http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html > > Any comments on the driver available directly from Intel? > http://support.intel.com/support/network/adapter/pro100/e100-1.0.0.htm > > 2) any ideas on what is causing this? It is quite possibly your network cards. The Intel chipsets have been playing up for a lot of people. You could try the driver in ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c, or switch NICs, whichever suits you best. There is also another, even more advanced version of the driver fixed by another member of this list, but I do not have the URL on me at the moment. Richard. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From rfowler@idcnet.com Tue Mar 7 01:02:13 2000 Date: Tue Mar 7 01:02:13 2000 From: Ron Fowler rfowler@idcnet.com Subject: eepro100: can't use tcpdump/promiscuous mode Hello, list gurus! I'm in the process of upgrading all our Linux servers to 100MB operation and Redhat Linux 6.1. The NIC I've selected is the Intel EtherExpress Pro 100, which is nicely supported by Redhat "out of the box". I've deployed about four of these in the last week or two, and a couple of days ago, I had to use one of them for a common task on our network: running tcpdump to trace packets when our dialup users have trouble with connectivity. After a period of tearing my hair out when I couldn't see any traffic, it dawned on me (and a quick check with ifconfig confirmed) that the NIC wasn't going into promiscuous mode! I checked all four servers configured with the eepro driver, and saw the same problem. The systems in question range from a Pentium P150 from 1997 to a P2-450 initially deployed with a 10 MB card last June. All have the same problem. And yet my 10MB NE2000-compatibles (Redhat 5.2) work fine. I've searched the beowulf eepro100 archives as well as Deja's Usenet archive, and can't locate a single report of this problem. So I'm wondering if I'm either missing something obvious or expecting something the EtherExpress Pro can't do. Thanks for any help anyone can give me ... Ron Fowler (rfowler@idcnet.com) System Administrator, Internet Dynamics Corp. 120 North Fraternity Lane Whitewater, WI 53190 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From techmail@fporch.com Tue Mar 7 11:38:50 2000 Date: Tue Mar 7 11:38:50 2000 From: The Techies techmail@fporch.com Subject: Some definitions What do these mean? frame: 2323 carrier: 0 --------------------------------------------------------------------------- eth0 Link encap:Ethernet HWaddr xx inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.xxx Mask:255.255.255.224 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:446637365 errors:7 dropped:0 overruns:0 frame:2323 TX packets:344384952 errors:0 dropped:0 overruns:0 carrier:0 collisions:31837183 txqueuelen:100 Interrupt:10 Base address:0xef00 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From richard@iguana.co.nz Tue Mar 7 17:38:28 2000 Date: Tue Mar 7 17:38:28 2000 From: richard@iguana.co.nz richard@iguana.co.nz Subject: eepro100: can't use tcpdump/promiscuous mode > > Hello, list gurus! > > The systems in question range from a Pentium P150 from 1997 to a P2-450 > initially deployed with a 10 MB card last June. All have the same problem. > And yet my 10MB NE2000-compatibles (Redhat 5.2) work fine. > > I've searched the beowulf eepro100 archives as well as Deja's Usenet > archive, and can't locate a single report of this problem. So I'm > wondering if I'm either missing something obvious or expecting something > the EtherExpress Pro can't do. > > Thanks for any help anyone can give me ... Hmm. Working fine on my machine, but I have seen this before, and not just with eepro NICs. You may wish to try ifconfig eth0 promisc or equivalent once you've started tcpdump, see if that helps. Richard ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From sarahjames@home.com Tue Mar 7 21:00:28 2000 Date: Tue Mar 7 21:00:28 2000 From: Sarah James sarahjames@home.com Subject: What does this mii-diag output mean? I'm having a hard time deciphering this output from mii-diag. The numbers don't match what is given in http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html Here it is: Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 40a1 0001 0000. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 40a1: 100baseTx 10baseT. The mode of the network we're connected to is supposed to be a 10MB full duplex. Does this output confirm that our Intel eepro sees this and is configured correctly? ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From becker@scyld.com Tue Mar 7 22:06:43 2000 Date: Tue Mar 7 22:06:43 2000 From: Donald Becker becker@scyld.com Subject: What does this mii-diag output mean? On Tue, 7 Mar 2000, Sarah James wrote: > I'm having a hard time deciphering this output from mii-diag. The numbers > don't match what is given in > http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html > > Here it is: > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 40a1 0001 0000. > Basic mode control register 0x3000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > Your link partner advertised 40a1: 100baseTx 10baseT. You have a 10baseT + 100baseT hub, likely a bridged repeater. > The mode of the network we're connected to is supposed to be a 10MB full > duplex. Nope, it's not. Donald Becker Scyld Computing Corporation, becker@scyld.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From richard@iguana.co.nz Tue Mar 7 23:00:17 2000 Date: Tue Mar 7 23:00:17 2000 From: richard@iguana.co.nz richard@iguana.co.nz Subject: What does this mii-diag output mean? On Tue, 7 Mar 2000, Sarah James wrote: > I'm having a hard time deciphering this output from mii-diag. The numbers > don't match what is given in > http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html > > Here it is: > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 40a1 0001 0000. > Basic mode control register 0x3000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > Your link partner advertised 40a1: 100baseTx 10baseT. > > The mode of the network we're connected to is supposed to be a 10MB full > duplex. > > Does this output confirm that our Intel eepro sees this and is configured > correctly? Well, I can confirm for one thing that if it detects as 100mbit and your network is only 10, it won't work at all :) So if you're suffering packet loss or slow connectivity, this is not the problem. Full/Half duplex I have not really encountered, and certainly that information doesn't appear to define whether you're on duplex or not, but I suspect that unless you're not recieving/transmitting anything at all then your auto detection has worked fine. At least in my experience, I am by no means a definitive answer on such issues, I fiddle until they work :) Richard. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Tue Mar 7 23:52:59 2000 Date: Tue Mar 7 23:52:59 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: What does this mii-diag output mean? Hello, On Tue, Mar 07, 2000 at 09:01:27PM -0500, Sarah James wrote: > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 40a1 0001 0000. > Basic mode control register 0x3000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > Your link partner advertised 40a1: 100baseTx 10baseT. > > > The mode of the network we're connected to is supposed to be a 10MB full > duplex. 1. Try to run mii-diag -v for more information. 2. Try to force the required mode either by driver or mii-diag. Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From kallol@bugula.fpk.hp.com Wed Mar 8 12:08:57 2000 Date: Wed Mar 8 12:08:57 2000 From: Kallol Biswas kallol@bugula.fpk.hp.com Subject: What does this mii-diag output mean? I am having a problem with the control register (REG0) of PHY. I wrote 0x3300 to it but when read back it became 0x0080 and the driver did not work. Any input on what might be the cause of this problem is greatly appreciated. > y On Tue, 7 Mar 2000, Sarah James wrote: > > > I'm having a hard time deciphering this output from mii-diag. The numbers > > don't match what is given in > > http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html > > > > Here it is: > > > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 40a1 0001 0000. > > Basic mode control register 0x3000: Auto-negotiation enabled. > > You have link beat, and everything is working OK. > > Your link partner advertised 40a1: 100baseTx 10baseT. > > > > The mode of the network we're connected to is supposed to be a 10MB full > > duplex. > > > > Does this output confirm that our Intel eepro sees this and is configured > > correctly? > > Well, I can confirm for one thing that if it detects as 100mbit and your > network is only 10, it won't work at all :) So if you're suffering packet > loss or slow connectivity, this is not the problem. Full/Half duplex I > have not really encountered, and certainly that information doesn't appear > to define whether you're on duplex or not, but I suspect that unless > you're not recieving/transmitting anything at all then your auto detection > has worked fine. > > At least in my experience, I am by no means a definitive answer on such > issues, I fiddle until they work :) > > Richard. > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > -- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From kallol@bugula.fpk.hp.com Wed Mar 8 12:13:21 2000 Date: Wed Mar 8 12:13:21 2000 From: Kallol Biswas kallol@bugula.fpk.hp.com Subject: What does this mii-diag output mean? Another problem, has any body seen the following prompt during system boot up: Press CTRL+S to enter into the set up program of Intel 100+ Pro adapter. > > I am having a problem with the control register (REG0) of PHY. > I wrote 0x3300 to it but when read back it became 0x0080 > and the driver did not work. > > Any input on what might be the cause of this problem is greatly > appreciated. > > > > > y On Tue, 7 Mar 2000, Sarah James wrote: > > > > > I'm having a hard time deciphering this output from mii-diag. The numbers > > > don't match what is given in > > > http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html > > > > > > Here it is: > > > > > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 40a1 0001 0000. > > > Basic mode control register 0x3000: Auto-negotiation enabled. > > > You have link beat, and everything is working OK. > > > Your link partner advertised 40a1: 100baseTx 10baseT. > > > > > > The mode of the network we're connected to is supposed to be a 10MB full > > > duplex. > > > > > > Does this output confirm that our Intel eepro sees this and is configured > > > correctly? > > > > Well, I can confirm for one thing that if it detects as 100mbit and your > > network is only 10, it won't work at all :) So if you're suffering packet > > loss or slow connectivity, this is not the problem. Full/Half duplex I > > have not really encountered, and certainly that information doesn't appear > > to define whether you're on duplex or not, but I suspect that unless > > you're not recieving/transmitting anything at all then your auto detection > > has worked fine. > > > > At least in my experience, I am by no means a definitive answer on such > > issues, I fiddle until they work :) > > > > Richard. > > > > ------------------------------------------------------------------- > > To unsubscribe send a message body containing "unsubscribe" > > to linux-eepro100-request@beowulf.org > > > > > -- > -- local ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From kallol@bugula.fpk.hp.com Wed Mar 8 13:34:20 2000 Date: Wed Mar 8 13:34:20 2000 From: Kallol Biswas kallol@bugula.fpk.hp.com Subject: What does this mii-diag output mean? I have solved this problem by increasing the delay value between write and read. > I am having a problem with the control register (REG0) of PHY. > I wrote 0x3300 to it but when read back it became 0x0080 > and the driver did not work. > > Any input on what might be the cause of this problem is greatly > appreciated. > > > > > y On Tue, 7 Mar 2000, Sarah James wrote: > > > > > I'm having a hard time deciphering this output from mii-diag. The numbers > > > don't match what is given in > > > http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html > > > > > > Here it is: > > > > > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 40a1 0001 0000. > > > Basic mode control register 0x3000: Auto-negotiation enabled. > > > You have link beat, and everything is working OK. > > > Your link partner advertised 40a1: 100baseTx 10baseT. > > > > > > The mode of the network we're connected to is supposed to be a 10MB full > > > duplex. > > > > > > Does this output confirm that our Intel eepro sees this and is configured > > > correctly? > > > > Well, I can confirm for one thing that if it detects as 100mbit and your > > network is only 10, it won't work at all :) So if you're suffering packet > > loss or slow connectivity, this is not the problem. Full/Half duplex I > > have not really encountered, and certainly that information doesn't appear > > to define whether you're on duplex or not, but I suspect that unless > > you're not recieving/transmitting anything at all then your auto detection > > has worked fine. > > > > At least in my experience, I am by no means a definitive answer on such > > issues, I fiddle until they work :) > > > > Richard. > > > > ------------------------------------------------------------------- > > To unsubscribe send a message body containing "unsubscribe" > > to linux-eepro100-request@beowulf.org > > > > > -- > -- local ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From markk@fb00.fb.com Wed Mar 8 13:45:11 2000 Date: Wed Mar 8 13:45:11 2000 From: Mark Krolikowski markk@fb00.fb.com Subject: REMOVE REMOVE ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From RKrawl@microtest.com Sat Mar 11 02:09:48 2000 Date: Sat Mar 11 02:09:48 2000 From: Krawl, Roeland RKrawl@microtest.com Subject: Possible flaw in the eepro100 driver version 1.09t This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8B28.B34CBB10 Content-Type: text/plain This seems to be the only forum for reporting eepro100 version 1.09t driver bugs and getting any kind of feedback (hopefully). The author of this driver has been unreachable for weeks therefore feedback from device driver programmers who have intimate knowledge of this driver would be appreciated. Other possible problems not mentioned here could be discussed also. To properly acknowledge "early receive" and "flow control paused" interrupts, it appears that the status mask should be 0xF300 instead of 0xFC00. Thanks, Roeland Krawl ------_=_NextPart_001_01BF8B28.B34CBB10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Possible flaw in the eepro100 driver version 1.09t

This seems to be the only forum for = reporting eepro100 version 1.09t driver bugs and getting any kind of = feedback (hopefully). The author of this driver has been unreachable = for weeks therefore feedback from device driver programmers who have = intimate knowledge of this driver would be appreciated. Other possible = problems not mentioned here could be discussed also.

To properly acknowledge "early = receive" and "flow control paused" interrupts, it = appears that the status mask should be 0xF300 instead of = 0xFC00.

Thanks,
Roeland Krawl

------_=_NextPart_001_01BF8B28.B34CBB10-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Mon Mar 13 04:44:07 2000 Date: Mon Mar 13 04:44:07 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: Possible flaw in the eepro100 driver version 1.09t On Sat, Mar 11, 2000 at 12:09:02AM -0700, Krawl, Roeland wrote: > This seems to be the only forum for reporting eepro100 version 1.09t driver > bugs and getting any kind of feedback (hopefully). The author of this driver > has been unreachable for weeks therefore feedback from device driver > programmers who have intimate knowledge of this driver would be appreciated. > Other possible problems not mentioned here could be discussed also. > > To properly acknowledge "early receive" and "flow control paused" > interrupts, it appears that the status mask should be 0xF300 instead of > 0xFC00. I suspect that the driver acknowledges interrupts that have a clear meaning and were well-documented at the beginning of driver development. All these "early receive" and "flow control paused" thing look fairly obscure at least for me. Do you have a clear description of what these kind of interrupts mean and when they're supposed to be triggered? Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From sarahjames@home.com Mon Mar 13 20:51:15 2000 Date: Mon Mar 13 20:51:15 2000 From: Sarah James sarahjames@home.com Subject: incompatibility between eepro100 and Cisco Catalyst switch? Has anyone heard of any compatibility issues between an eepro and a Cisco Catalyst switch? Our server works perfectly with a no name NE2000 compatible NIC, but has problems if we try the eepro100. (regardless of the mode I manually place it in). We are connecting to a Cisco Catalyst switch. ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From RKrawl@microtest.com Mon Mar 13 23:05:11 2000 Date: Mon Mar 13 23:05:11 2000 From: Krawl, Roeland RKrawl@microtest.com Subject: Possible flaw in the eepro100 driver version 1.09t This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8D6A.682EBDE0 Content-Type: text/plain As a result of an 82559ER initialization problem, continuous "flow control paused" interrupts were causing our Linux system to hang. The eepro100 driver does not acknowledge the flow control paused interrupts. Another symptom of the initialization problem was that the 82559ER was reporting a status which indicated "no resources" and "No Rx bufs". The initialization problem was fixed by modifying the speedo_resume() routine slightly. After each call to "wait_for_cmd_done()" we added a call to uwait() to delay 30 microseconds. This ensures that the NIC has a little extra time to examine the System Control Block General Pointer before the driver changes it in preparation for sending the next command. Apparently, the 82559 was reporting "no Rx bufs" as a result of obtaining a bogus pointer to the Rx Ring because the real Rx ring was known to be properly initialized and Rx resources were definitely available. The cure described above was difficult to find because small changes to the eepro100 driver or other parts of the Linux kernel would cause the symptom to go away. The symptom would also go away by simply re-ordering the object file names in the kernel/drivers/net/Makefile. Roeland Krawl > -----Original Message----- > From: Andrey Savochkin [SMTP:saw@saw.sw.com.sg] > Sent: Monday, March 13, 2000 2:44 AM > To: Krawl, Roeland; 'linux-eepro100@beowulf.gsfc.nasa.gov' > Subject: Re: Possible flaw in the eepro100 driver version 1.09t > > On Sat, Mar 11, 2000 at 12:09:02AM -0700, Krawl, Roeland wrote: > > This seems to be the only forum for reporting eepro100 version 1.09t > driver > > bugs and getting any kind of feedback (hopefully). The author of this > driver > > has been unreachable for weeks therefore feedback from device driver > > programmers who have intimate knowledge of this driver would be > appreciated. > > Other possible problems not mentioned here could be discussed also. > > > > To properly acknowledge "early receive" and "flow control paused" > > interrupts, it appears that the status mask should be 0xF300 instead of > > 0xFC00. > > I suspect that the driver acknowledges interrupts that have a clear > meaning > and were well-documented at the beginning of driver development. > All these "early receive" and "flow control paused" thing look fairly > obscure > at least for me. > > Do you have a clear description of what these kind of interrupts mean and > when they're supposed to be triggered? > > Best regards > Andrey V. > Savochkin > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org ------_=_NextPart_001_01BF8D6A.682EBDE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Possible flaw in the eepro100 driver version 1.09t

As a result of an = 82559ER initialization problem, continuous "flow control = paused" interrupts were causing our Linux system to hang. The = eepro100 driver does not acknowledge the flow control paused = interrupts. Another symptom of the initialization problem was that the = 82559ER was reporting a status which indicated "no resources" = and "No Rx bufs".

The initialization = problem was fixed by modifying the speedo_resume() routine slightly. = After each call to "wait_for_cmd_done()" we added a call to = uwait() to delay 30 microseconds. This ensures that the NIC has a = little extra time to examine the System Control Block General Pointer = before the driver changes it in preparation for sending the next = command.

Apparently, the = 82559 was reporting "no Rx bufs" as a result of obtaining a = bogus pointer to the Rx Ring because the real Rx ring was known to be = properly initialized and Rx resources were definitely available. =

The cure described = above was difficult to find because small changes to the eepro100 = driver or other parts of the Linux kernel would cause the symptom to go = away. The symptom would also go away by simply re-ordering the object = file names in the kernel/drivers/net/Makefile.

Roeland = Krawl

-----Original Message-----
From:   Andrey Savochkin = [SMTP:saw@saw.sw.com.sg]
Sent:   Monday, March 13, 2000 2:44 AM
To:     Krawl, Roeland; = 'linux-eepro100@beowulf.gsfc.nasa.gov'
Subject:       = Re: Possible flaw in the eepro100 = driver version 1.09t

On Sat, Mar 11, 2000 at 12:09:02AM = -0700, Krawl, Roeland wrote:
> This seems to be the only forum = for reporting eepro100 version 1.09t driver
> bugs and getting any kind of = feedback (hopefully). The author of this driver
> has been unreachable for weeks = therefore feedback from device driver
> programmers who have intimate = knowledge of this driver would be appreciated.
> Other possible problems not = mentioned here could be discussed also.
>
> To properly acknowledge = "early receive" and "flow control paused"
> interrupts, it appears = that the status mask should be 0xF300 instead of
> 0xFC00.

I suspect that the driver acknowledges = interrupts that have a clear meaning
and were well-documented at the = beginning of driver development.
All these "early receive" = and "flow control paused" thing look fairly obscure
at least for me.

Do you have a clear description of = what these kind of interrupts mean and
when they're supposed to be = triggered?

Best regards
= = = = Andrey V.
= = = = Savochkin
---------------------------------------------------------= ----------
To unsubscribe send a message body = containing "unsubscribe"
to = linux-eepro100-request@beowulf.org

------_=_NextPart_001_01BF8D6A.682EBDE0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jeff.binkley@asacomp.com Tue Mar 14 12:03:08 2000 Date: Tue Mar 14 12:03:08 2000 From: Jeff Binkley jeff.binkley@asacomp.com Subject: INCOMPATIBILITY BETWEEN E CC: SARAHJAMES@HOME.COM linux-eepro100@beowulf.gsfc.nasa.gov Working here fine with a 3524. I did have problems with a Synoptics 28K switch. Had to leave them at 100M helf-duplex. It is a known problem for the 28k's not an EEPRO problem. Jeff Binkley ASA Network Computing S>Has anyone heard of any compatibility issues between an eepro and a S>Cisco Catalyst switch? S>Our server works perfectly with a no name NE2000 compatible NIC, but S>has problems if we try the eepro100. (regardless of the mode I S>manually place it in). S>We are connecting to a Cisco Catalyst switch. S>------------------------------------------------------------------- S>To unsubscribe send a message body containing "unsubscribe" S>to linux-eepro100-request@beowulf.org S> CMPQwk 1.42 9999 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From luis@mecha.barry.edu Tue Mar 14 12:21:44 2000 Date: Tue Mar 14 12:21:44 2000 From: Luis Muench luis@mecha.barry.edu Subject: status=0x4050 Hi: I am having problems with an intel eepro100 nic. I keep getting "eth0: Too much work at interrupt, status=0x4050" errors at the console...sometimes the machine becomes unusable over the network and I have to restart...any ideas RH4.2 w/all patches, driver is eepro v0.99B...never really had problems with this until recently... Any ideas are welcome -------------------------------------------------- Luis Muench Project MECHA Webmaster ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From mrensing@uvic.ca Tue Mar 14 18:31:04 2000 Date: Tue Mar 14 18:31:04 2000 From: Michael J. Rensing mrensing@uvic.ca Subject: Transmit timed out: which driver is best now? Hi, I've got a 39 node cluster running, all with the Intel 82588 chip. Currently, the systems are running a 2.2.12-20 kernel with the 1.06 eepro100 drivers. I'm getting the "Transmit timed out / Trying to restart the transmitter" problem so many people have been discussing. Can anyone tell me what the best (current) solution is? a) upgrade to 1.09l b) use Intel drivers c) use Andrei's drivers (where do I get them) d) other solution Also, will this really fix things, or could I be risking further problems? -- Michael ------------------------------------------------------------ Dr. Michael J. Rensing | mailto:mrensing@uvic.ca Physics and Astronomy | phone: 250-721-7741 University of Victoria | fax: 250-721-7752 ------------------------------------------------------------ ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Tue Mar 14 21:11:02 2000 Date: Tue Mar 14 21:11:02 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: Transmit timed out: which driver is best now? Hello, On Tue, Mar 14, 2000 at 03:30:58PM -0800, Michael J. Rensing wrote: > I've got a 39 node cluster running, all with the Intel 82588 chip. > Currently, the systems are running a 2.2.12-20 kernel with the 1.06 > eepro100 drivers. I'm getting the "Transmit timed out / Trying to > restart the transmitter" problem so many people have been discussing. > > Can anyone tell me what the best (current) solution is? > a) upgrade to 1.09l > b) use Intel drivers > c) use Andrei's drivers (where do I get them) > d) other solution I recommend (c) :-) The necessary changes are incorporated into 2.2.15pre13 and later kernels in ftp.kernel.org/pub/linux/kernel/people/alan/2.2.15pre/ For 2.3 kernels the driver is available at ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.3/ > > Also, will this really fix things, or could I be risking further > problems? My changes address exactly the core reasons of the problems and implement - accurate tbusy management without race conditions (except the one forced by the hardware design) - correct buffer ring refilling (the usual reason for card hangs and thus timeouts, happen under high load) - correct multicast list setup (avoiding stray pointers in the TX ring) - thoroughly tested TX timeout handler to avoid looping timeouts because of incomplete reset and reconfiguration. I haven't heard about more problems with my clone of the driver (except not clear problems with 82559ER cards and interrupt acknowledgement). I personally use this version driver on rather loaded and critical servers. Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From bcotton@synxis.com Wed Mar 15 14:26:33 2000 Date: Wed Mar 15 14:26:33 2000 From: Bob Cotton bcotton@synxis.com Subject: Intel EePro100 Dual Port and Failover Does anyone know if there is a linux driver the Intel Dual Port eePro that supports the failover mode from one port to the other? Or do we have to code this ourselves? Thanks, - Bob -- SynXis Corporation | bob@synxis.com | Mediocrity: it takes a lot less 1610 Wynkoop, Suite 400 | Ph: (303)595-2511 | time, and most people won't notice Denver, CO 80202 | Fax:(303)534-4257 | the difference until it's too late ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From sjw999@netvigator.com Fri Mar 17 20:15:16 2000 Date: Fri Mar 17 20:15:16 2000 From: Stephen Williams sjw999@netvigator.com Subject: collisions with 1.09t -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings � I recently recompiled my kernel and after found that I was getting massive collisions on the NIC under heavy load (which are enough to disconnect the NIC if allowed to continue). I had not noticed these problems previously. I tried retrogrades and recompiles but to no effect. I�ve also tried swapping the NIC for an older model with a different chip. No difference. My hub is not one of the best. When I remove the hub and connect via a crossover cable to an identical NIC the collision problem vanishes. Incidentally, the same model NIC connected to the same hub making the same transfers under Windows produces no collisions. My long-term solution will be to replace the hub with a better quality unit but I am isolated and cannot do this immediately. (I had planned to do this anyway.) So my question is, how might I detune the NIC so as to reduce the collision problem? In Intel�s Windows drivers it is possible to do so. Is there any way of doing this with eepro100? Also, how might I check to be sure that the NIC is not erroneously defaulting to full duplex? My impression is that this problem does have something to do with eepro100. It seems to show up only under certain circumstances and then only under the heaviest of loads. I suspect that the recompile did do something as I am reasonably sure that this problem didn�t exist previously (the only change I made was to CONFIG_FILTER). Also it seems to occur only under the heaviest of loads (for example, FTP isn�t a problem but transfers under SAMBA are). It wouldn�t surprise me if the authors are not experiencing this problem because they are using better equipment. But likely the common man will. FYI, here is the technical info on my NIC (thought as I said, I�ve tried other older models) and eepro100 version (which is now running under 2.2.15pre15): eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.3 $ 2000/03/02 Modified by Andrey V. Savochkin and others eth0: Intel PCI EtherExpress Pro100 at 0xc2826000, 00:90:27:BB:18:3E, IRQ 11. Receiver lock-up bug exists -- enabling work-around. Board assembly 721383-007, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). If I can provide any other info please ask. Best, S. ========================================================== PGP keys: http://www.ucc.uconn.edu/~jewil/sjw.html RSA: 4E11 E5BB 3F2D E856 AC10 2F49 5C82 9BBB DH/DSS: DCED DE1E F46C 1081 B67E B3A7 1EC1 AC37 2E69 04C4 ========================================================== -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.3 iQA/AwUBONLYmh7BrDcuaQTEEQKT1gCgqT3QLuhnhoy6qTmZU69qugvyacYAoJQr G7djb4g7Jytr8VUXoy52Fl7b =I0HD -----END PGP SIGNATURE----- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Fri Mar 17 22:56:25 2000 Date: Fri Mar 17 22:56:25 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: collisions with 1.09t Hello, On Sat, Mar 18, 2000 at 01:15:06AM -0000, Stephen Williams wrote: > I recently recompiled my kernel and after found that I was getting massive > collisions on the NIC under heavy load (which are enough to disconnect the > NIC if allowed to continue). I had not noticed these problems previously. I > tried retrogrades and recompiles but to no effect. [snip] > So my question is, how might I detune the NIC so as to reduce the collision > problem? In Intel�s Windows drivers it is possible to do so. Is there any > way of doing this with eepro100? > > Also, how might I check to be sure that the NIC is not erroneously > defaulting to full duplex? As far as I can tell, by default the driver keep transmitter's parameters (speed and duplex) uninitialized. So it may appear that your card works in full duplex mode with autonegotiation turned off. You may check the current mode by mii-diag program (the link to this program may be found on http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html). To solve your problems try to specify explicitly the desired mode by passing options to the driver. Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From lovehalfdome@hotmail.com Sat Mar 18 01:48:41 2000 Date: Sat Mar 18 01:48:41 2000 From: John Muir lovehalfdome@hotmail.com Subject: multicast issue on eepro100 I have a linux box functioning as a proxy/cache using Squid. I us ip_fwd to route all non-web traffic past the box. I get the infamous Transmit error now and then. Do I need multicast at all? Is it enough to limit multicast to 3? I can disable it in ifconfig? Does this help me? Should I recompile without multicast? I am using 1.2l eepro100.o on 2.2.5-22 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From lovehalfdome@hotmail.com Sat Mar 18 01:52:33 2000 Date: Sat Mar 18 01:52:33 2000 From: John Muir lovehalfdome@hotmail.com Subject: Andrey's eepro100.o version Andrey: Where can I get just the source eepro100.c for your driver without having to flesh it out of the whole kernel? Steve At 10:11 AM 3/15/00 +0800, you wrote: >Hello, > >On Tue, Mar 14, 2000 at 03:30:58PM -0800, Michael J. Rensing wrote: >>I've got a 39 node cluster running, all with the Intel 82588 chip. >>Currently, the systems are running a 2.2.12-20 kernel with the 1.06 >>eepro100 drivers. I'm getting the "Transmit timed out / Trying to >>restart the transmitter" problem so many people have been discussing. >> >>Can anyone tell me what the best (current) solution is? >>a) upgrade to 1.09l >>b) use Intel drivers >>c) use Andrei's drivers (where do I get them) >>d) other solution > >I recommend (c) :-) >The necessary changes are incorporated into 2.2.15pre13 and later kernels >in ftp.kernel.org/pub/linux/kernel/people/alan/2.2.15pre/ > >For 2.3 kernels the driver is available at >ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.3/ > >> >>Also, will this really fix things, or could I be risking further >>problems? > >My changes address exactly the core reasons of the problems and implement >- accurate tbusy management without race conditions (except the one forced > by the hardware design) >- correct buffer ring refilling (the usual reason for card hangs and > thus timeouts, happen under high load) >- correct multicast list setup (avoiding stray pointers in the TX ring) >- thoroughly tested TX timeout handler to avoid looping timeouts because of > incomplete reset and reconfiguration. > >I haven't heard about more problems with my clone of the driver (except not >clear problems with 82559ER cards and interrupt acknowledgement). I >personally use this version driver on rather loaded and critical servers. > >Best regards > Andrey V. > Savochkin ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From becker@scyld.com Sat Mar 18 03:31:30 2000 Date: Sat Mar 18 03:31:30 2000 From: Donald Becker becker@scyld.com Subject: collisions with 1.09t On Sat, 18 Mar 2000, Andrey Savochkin wrote: > > > > Also, how might I check to be sure that the NIC is not erroneously > > defaulting to full duplex? > > As far as I can tell, by default the driver keep transmitter's parameters > (speed and duplex) uninitialized. So it may appear that your card works in > full duplex mode with autonegotiation turned off. The hardware initializes itself to autonegotiation, advertising the standard set of capabilities. There is a reason for not explicitly setting the transceiver register by default. Initializing the settings, without an explicit specification of media type, will break forward compatibility. Vis. the addition of flow control -- if the earlier drivers had initialized the advertised capabilities, the flow control feature would have been disabled. > You may check the current mode by mii-diag program (the link to this program > may be found on http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html). A better URL is http://cesdis.gsfc.nasa.gov/linux/diag/index.html or http://www.scyld.com/diag/index.html Donald Becker Scyld Computing Corporation, becker@scyld.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From sjw999@netvigator.com Sat Mar 18 04:02:53 2000 Date: Sat Mar 18 04:02:53 2000 From: Stephen Williams sjw999@netvigator.com Subject: collisions with 1.09t -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrey, First, I left off a "0" in my original message. In fact the hub is 100baseTX, half-duplex only (it cannot support 10baseT). Now, MII-DIAG reports the hub as advertising "0081". From the page: http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html I read that to mean "0x0080 100baseTx supported" and "0x001F Protocol selection bits, always 0x0001 for Ethernet". Have I made a mistake? This is what I would expect. Now, given the above, is there any way that the NIC could be operating in full-duplex mode? Is it worth my testing this? (I presume that I would use the option 0x20?) I have since confirmed that I am getting similar errors on other computers -- just not quite as bad. To give you an idea of how bad this is: eth0 Link encap:Ethernet HWaddr 00:90:27:BB:18:3E inet addr:192.168.11.10 Bcast:192.168.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:500571 errors:0 dropped:0 overruns:0 frame:0 TX packets:587848 errors:0 dropped:0 overruns:0 carrier:0 collisions:213150 txqueuelen:100 Interrupt:11 Base address:0x2000 When the same NIC is operated under Win2000 on the same hub I might get 1 collision with 500,000 packets. All the best, S. > -----Original Message----- > From: Andrey Savochkin [mailto:saw@saw.sw.com.sg] > Sent: Saturday, 18 March 2000 04:28 > To: Stephen Williams > Subject: Re: collisions with 1.09t > > > On Sat, Mar 18, 2000 at 04:09:45AM -0000, Stephen Williams wrote: > > In fact, just as you wrote I had finished playing with > MII-DIAG. Here is > > what I got: > > > > Using the default interface 'eth0'. > > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 > 0081 0000 0000. > > Basic mode control register 0x3000: Auto-negotiation enabled. > > You have link beat, and everything is working OK. > > Your link partner is generating 100baseTx link beat (no > autonegotiation). > > That's a bogus report. > > > > > Since the partner is being read as "0081" I would think > that the NIC would > > negotiate 10baseTX half-duplex so I have come to the > conclusion that that is > > not the problem. > > Yeah, it's truly 10Mbit/s half-duplex. > > > > > But in any case, I looked at the info page on the eepro100 > and it does not > > list explcitly the code for half-duplex -- just for full duplex. > > Zero bit for full-duplex bit means half-duplex. > So just pass zero options. > > > With Intel's drivers for Windows there is an advanced option called > > "Adaptive Inter-Frame Spacing" which the help file defines as: > [snip] > > I looked at the source to see if there was any way of > performing the same > > function with the eepro100 driver but could not see it. Is > it possible?? > > No, it isn't. Introducing such an option may create > different problems > without any good reason. Such an option isn't ever needed. > For your case > isn't it better to fix the origin of the problem (duplex > setting of the card) > instead of introducing such stupid delays? > > Best regards > Andrey V. > Savochkin -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.3 iQA/AwUBONNGKh7BrDcuaQTEEQKKYgCfSJnwh+noZn9NhBe5PUG/wspr3vkAoOaU gawLIGfNDVG748KVD9eOOP+d =4fWs -----END PGP SIGNATURE----- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Sun Mar 19 21:44:33 2000 Date: Sun Mar 19 21:44:33 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: Andrey's eepro100.o version On Fri, Mar 17, 2000 at 10:51:57PM -0800, John Muir wrote: > Andrey: > > Where can I get just the source eepro100.c for your driver without having > to flesh it out of the whole kernel? Well, according to the public demand :-) I've put the driver version for 2.2 kernels on my ftp site too: ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.2/ Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From lovehalfdome@hotmail.com Mon Mar 20 00:34:14 2000 Date: Mon Mar 20 00:34:14 2000 From: John Muir lovehalfdome@hotmail.com Subject: Andrey's eepro100.o version Andrey: FYI. I just compiled and installed the new driver on our problem equipment. It worked perfectly. We found that Appletalk caused the problem for us. We loaded our Sniffer Pro with Appletalk and ran it at high speed onto the Network. Crashed it very easily with the old driver and worked fine with yours. Thanks for your contributions to the eepro stuff (not to minimize Donald Becker -- without whom we would not have had a driver at all). Steve >From: Andrey Savochkin >To: John Muir >CC: linux-eepro100@beowulf.gsfc.nasa.gov >Subject: Re: Andrey's eepro100.o version >Date: Mon, 20 Mar 2000 10:44:33 +0800 > >On Fri, Mar 17, 2000 at 10:51:57PM -0800, John Muir wrote: > > Andrey: > > > > Where can I get just the source eepro100.c for your driver without >having > > to flesh it out of the whole kernel? > >Well, according to the public demand :-) I've put the driver version for >2.2 >kernels on my ftp site too: >ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.2/ > >Best regards > Andrey V. > Savochkin >------------------------------------------------------------------- >To unsubscribe send a message body containing "unsubscribe" >to linux-eepro100-request@beowulf.org ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jcagle@houston.rr.com Tue Mar 21 10:00:45 2000 Date: Tue Mar 21 10:00:45 2000 From: John Cagle jcagle@houston.rr.com Subject: eepro100 - more than 8 NICs? This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF9313.CC6954E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know if the eepro100 driver will support more than 8 = interfaces in one machine? For instance, could you have 5 dual-port = cards working at the same time? On another topic, has anyone noticed that the = http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html site doesn't = seem to be working? However, if you replace "cesdis" with "beowulf" it = works!? Problem is that the site has a lot of hard-coded HREF's to = 'cesdis' that still won't work. Thanks, John Cagle ------=_NextPart_000_000D_01BF9313.CC6954E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does anyone know if the eepro100 driver = will=20 support more than 8 interfaces in one machine? For instance, could = you=20 have 5 dual-port cards working at the same time?

On another topic, has anyone noticed = that=20 the http://cesdis.gsfc.nasa.gov/linu= x/drivers/eepro100.html=20 site doesn't seem to be working? However, if you replace "cesdis" = with=20 "beowulf" it works!? Problem is that the site has a lot of = hard-coded=20 HREF's to 'cesdis' that still won't work.

Thanks,

John Cagle

------=_NextPart_000_000D_01BF9313.CC6954E0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From markk@fb00.fb.com Tue Mar 21 10:42:33 2000 Date: Tue Mar 21 10:42:33 2000 From: Mark Krolikowski markk@fb00.fb.com Subject: eepro100 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From markk@fb00.fb.com Tue Mar 21 10:42:52 2000 Date: Tue Mar 21 10:42:52 2000 From: Mark Krolikowski markk@fb00.fb.com Subject: eepro100 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From markk@fb00.fb.com Tue Mar 21 10:43:30 2000 Date: Tue Mar 21 10:43:30 2000 From: Mark Krolikowski markk@fb00.fb.com Subject: eepro100 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From Francois.Guimond@Matrox.COM Tue Mar 21 13:44:04 2000 Date: Tue Mar 21 13:44:04 2000 From: Francois Guimond Francois.Guimond@Matrox.COM Subject: eepro100 - more than 8 NICs? --------------C0FAA21F89C96705900F16DC Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit You have to odify the driver for that: Line 569 of the eepro100.c should look like: for (; pci_index < 8; pci_index++) { Change the number 8 to the number of ethernet controller you have... Follow instructions at the end of the file to recompile the module. Follow instructions at http://cesdis.gsfc.nasa.gov/linux/misc/modules.html to install it. John Cagle wrote: > Does anyone know if the eepro100 driver will support more than 8 > interfaces in one machine? For instance, could you have 5 dual-port > cards working at the same time? On another topic, has anyone noticed > that the http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html site > doesn't seem to be working? However, if you replace "cesdis" with > "beowulf" it works!? Problem is that the site has a lot of hard-coded > HREF's to 'cesdis' that still won't work. Thanks,John Cagle -- Fran�ois Guimond Matrox Networks Email: Francois.Guimond@matrox.com Web: http://www.matrox.com/netweb/home.htm Phone: (514) 822-6000 x2565 Fax: (514) 822-6272 --------------C0FAA21F89C96705900F16DC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit You have to odify the driver for that:

Line 569 of the eepro100.c should look like:
for (; pci_index < 8; pci_index++) {

Change the number 8 to the number of ethernet controller you have...

Follow instructions at the end of the file to recompile the module.
Follow instructions at http://cesdis.gsfc.nasa.gov/linux/misc/modules.html to install it.

John Cagle wrote:

Does anyone know if the eepro100 driver will support more than 8 interfaces in one machine? For instance, could you have 5 dual-port cards working at the same time? On another topic, has anyone noticed that the http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html site doesn't seem to be working? However, if you replace "cesdis" with "beowulf" it works!? Problem is that the site has a lot of hard-coded HREF's to 'cesdis' that still won't work. Thanks,John Cagle

--
François Guimond
Matrox Networks
Email: Francois.Guimond@matrox.com
Web: http://www.matrox.com/netweb/home.htm
Phone: (514) 822-6000 x2565
Fax: (514) 822-6272
--------------C0FAA21F89C96705900F16DC-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jgarzik@mandrakesoft.com Tue Mar 21 16:05:16 2000 Date: Tue Mar 21 16:05:16 2000 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: eepro100 - more than 8 NICs? > John Cagle wrote: > > Does anyone know if the eepro100 driver will support more than 8 > interfaces in one machine? For instance, could you have 5 dual-port > cards working at the same time? eepro100 kernel driver in 2.3.x should not have any hard limit at all, and most of Becker's drivers should handle simply increasing the number of net cards you can probe. Note that 8 is a hardcoded number all over the place -- so if you need module options to work past card #8, you must hack the driver in a few more places... -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From John.Cagle@COMPAQ.com Tue Mar 21 16:54:03 2000 Date: Tue Mar 21 16:54:03 2000 From: Cagle, John John.Cagle@COMPAQ.com Subject: eepro100 - more than 8 NICs? This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF937F.E41F00F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This seems like an incomplete solution. Shouldn't you also increase = the size of the 'full_duplex' and 'options' arrays? The code from the 1.06 version (from kernel 2.2.14) has these definitions: =20 static int full_duplex[] =3D {-1, -1, -1, -1, -1, -1, -1, -1}; static int options[] =3D {-1, -1, -1, -1, -1, -1, -1, -1}; =20 Shouldn't these be increased to be at least as large as the maximum pci_index? I also noticed that 'pci_index' has been removed from the = driver in the latest 2.3 kernel (v1.09j+LK1.0). =20 Who is the current maintainer of this driver? =20 Thanks, John Cagle -----Original Message----- From: Francois Guimond [mailto:Francois.Guimond@Matrox.COM] Sent: Tuesday, March 21, 2000 12:42 PM To: John Cagle Cc: linux-eepro100@beowulf.gsfc.nasa.gov Subject: Re: eepro100 - more than 8 NICs? You have to odify the driver for that:=20 Line 569 of the eepro100.c should look like:=20 for (; pci_index < 8; pci_index++) {=20 Change the number 8 to the number of ethernet controller you have...=20 Follow instructions at the end of the file to recompile the module.=20 Follow instructions at = http://cesdis.gsfc.nasa.gov/linux/misc/modules.html to install it.=20 John Cagle wrote:=20 Does anyone know if the eepro100 driver will support more than 8 = interfaces in one machine? For instance, could you have 5 dual-port cards working = at the same time? On another topic, has anyone noticed that the http://cesdis.gsfc.nasa.gov /linux/drivers/eepro100.html site doesn't seem to be working? However, = if you replace "cesdis" with "beowulf" it works!? Problem is that the = site has a lot of hard-coded HREF's to 'cesdis' that still won't work. = Thanks,John Cagle=20 --=20 Fran=E7ois Guimond=20 Matrox Networks=20 Email: Francois.Guimond@matrox.com=20 Web: http://www.matrox.com/netweb/home.htm =20 Phone: (514) 822-6000 x2565=20 Fax: (514) 822-6272=20 =20 ------_=_NextPart_001_01BF937F.E41F00F0 Content-Type: text/html; charset="iso-8859-1"

This seems like an incomplete solution. Shouldn't you also increase the size of the 'full_duplex' and 'options' arrays? The code from the 1.06 version (from kernel 2.2.14) has these definitions:

static int full_duplex[] = {-1, -1, -1, -1, -1, -1, -1, -1};

static int options[] = {-1, -1, -1, -1, -1, -1, -1, -1};

Shouldn't these be increased to be at least as large as the maximum pci_index? I also noticed that 'pci_index' has been removed from the driver in the latest 2.3 kernel (v1.09j+LK1.0).

Who is the current maintainer of this driver?

Thanks,

John Cagle

-----Original Message-----
From: Francois Guimond [mailto:Francois.Guimond@Matrox.COM]
Sent: Tuesday, March 21, 2000 12:42 PM
To: John Cagle
Cc: linux-eepro100@beowulf.gsfc.nasa.gov
Subject: Re: eepro100 - more than 8 NICs?

You have to odify the driver for that:
Line 569 of the eepro100.c should look like:
for (; pci_index < 8; pci_index++) {
Change the number 8 to the number of ethernet controller you have...
Follow instructions at the end of the file to recompile the module.
Follow instructions at http://cesdis.gsfc.nasa.gov/linux/misc/modules.html to install it.
John Cagle wrote:
Does anyone know if the eepro100 driver will support more than 8 interfaces in one machine? For instance, could you have 5 dual-port cards working at the same time? On another topic, has anyone noticed that the http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html site doesn't seem to be working? However, if you replace "cesdis" with "beowulf" it works!? Problem is that the site has a lot of hard-coded HREF's to 'cesdis' that still won't work. Thanks,John Cagle

--
Fran�ois Guimond
Matrox Networks
Email: Francois.Guimond@matrox.com
Web: http://www.matrox.com/netweb/home.htm
Phone: (514) 822-6000 x2565
Fax: (514) 822-6272

------_=_NextPart_001_01BF937F.E41F00F0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jgarzik@mandrakesoft.com Tue Mar 21 18:55:47 2000 Date: Tue Mar 21 18:55:47 2000 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: eepro100 - more than 8 NICs? > > This seems like an incomplete solution. Shouldn't you also increase the size of the 'full_duplex' and 'options' arrays? The > code from the 1.06 version (from kernel 2.2.14) has these definitions: > Correct, that is an incomplete solution. However, most of the Becker drivers has code in them that looks like priv->full_duplex = (idx >= 8) ? 0 : options[idx]; They are thus proof against >8 cards, but not functioning optimally. -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Tue Mar 21 20:32:03 2000 Date: Tue Mar 21 20:32:03 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: eepro100 - more than 8 NICs? Hello, On Tue, Mar 21, 2000 at 03:53:28PM -0600, Cagle, John wrote: > This seems like an incomplete solution. Shouldn't you also increase the > size of the 'full_duplex' and 'options' arrays? The code from the 1.06 > version (from kernel 2.2.14) has these definitions: > > static int full_duplex[] = {-1, -1, -1, -1, -1, -1, -1, -1}; > static int options[] = {-1, -1, -1, -1, -1, -1, -1, -1}; > > Shouldn't these be increased to be at least as large as the maximum I'll think about a solution for the problem. > pci_index? I also noticed that 'pci_index' has been removed from the driver > in the latest 2.3 kernel (v1.09j+LK1.0). > > Who is the current maintainer of this driver? A good question :-) I'm going to submit to Linus a set of serious modifications and take care of the driver in the future. Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From dhinds@valinux.com Mon Mar 27 02:40:38 2000 Date: Mon Mar 27 02:40:38 2000 From: David Hinds dhinds@valinux.com Subject: Intel PRO/100 Cardbus II with 82559 chip On Sun, Mar 26, 2000 at 11:51:42PM -0700, John Matthews wrote: > Dave, > I tried that patch and only one of five hunks succeeded on the patch. > The patch is dated June 1999 so I'm wondering if there might be something > newer. You are welcome to try to patch the driver by hand, but as I said, I have not even tested the patch I sent you (I don't have any such card), and no one seems to want to work on it, so you're more or less on your own. If I had more time, I'd offer to help, but I have to give a higher priority to fixing problems with cards that are already supposed to be supported. > Donald Becker's Web page says that his driver supports cardbus but I > can't find any directions on how to install it for cardbus. I would not hold my breath waiting for a response; Donald stopped supporting his drivers about six months ago. The driver does not support Cardbus as is: the web page is wrong. -- Dave ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From dhinds@valinux.com Mon Mar 27 03:06:29 2000 Date: Mon Mar 27 03:06:29 2000 From: David Hinds dhinds@valinux.com Subject: Intel PRO/100 Cardbus II with 82559 chip On Sun, Mar 26, 2000 at 11:51:42PM -0700, John Matthews wrote: > Dave, > I tried that patch and only one of five hunks succeeded on the patch. > The patch is dated June 1999 so I'm wondering if there might be something > newer. You are welcome to try to patch the driver by hand, but as I said, I have not even tested the patch I sent you (I don't have any such card), and no one seems to want to work on it, so you're more or less on your own. If I had more time, I'd offer to help, but I have to give a higher priority to fixing problems with cards that are already supposed to be supported. > Donald Becker's Web page says that his driver supports cardbus but I > can't find any directions on how to install it for cardbus. I would not hold my breath waiting for a response; Donald stopped supporting his drivers about six months ago. The driver does not support Cardbus as is: the web page is wrong. -- Dave ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From mike@tc3net.com Mon Mar 27 16:53:13 2000 Date: Mon Mar 27 16:53:13 2000 From: Michael Baird mike@tc3net.com Subject: Poor Performance I'm having a problem with throughput with my intel eepro100 nic's. I'm using them under 2.2.15pre15 per recommendations on this list, using arcserve client w eepro-100's I get very poor performance and high cpu utilization, my linux boxes are all dual-PII 300's, our hub is a 10/100 Officeconnect by 3COM. I've forced this card to full-duplex/100MB and mii-diag confirms this, but it doesn't help with my backup operations, 6MB/s is horrible. With 3com NIC's I get around 30mb on identical configured linux box, is there something I'm missing, or any other diagnostic tool I can try, I really would rather use Intel NIC's rather then 3Com's. Thanks MIKE ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From mike@tc3net.com Mon Mar 27 17:30:24 2000 Date: Mon Mar 27 17:30:24 2000 From: Michael Baird mike@tc3net.com Subject: Poor Performance I'm having a problem with throughput with my intel eepro100 nic's. I'm using them under 2.2.15pre15 per recommendations on this list, using arcserve client w eepro-100's I get very poor performance and high cpu utilization, my linux boxes are all dual-PII 300's, our hub is a 10/100 Officeconnect by 3COM. I've forced this card to full-duplex/100MB and mii-diag confirms this, but it doesn't help with my backup operations, 6MB/s is horrible. With 3com NIC's I get around 30mb on identical configured linux box, is there something I'm missing, or any other diagnostic tool I can try, I really would rather use Intel NIC's rather then 3Com's. Thanks MIKE ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From abyee@sfu.ca Mon Mar 27 23:08:15 2000 Date: Mon Mar 27 23:08:15 2000 From: Adrian Yee abyee@sfu.ca Subject: Poor Performance Mike, 6MegaBytes/second of 6Megabits/second? 30MB/s or 30mb/s? Adrian On Mon, 27 Mar 2000, Michael Baird wrote: > I'm having a problem with throughput with my intel eepro100 nic's. I'm > using them under 2.2.15pre15 per recommendations on this list, using > arcserve client w eepro-100's I get very poor performance and high cpu > utilization, my linux boxes are all dual-PII 300's, our hub is a 10/100 > Officeconnect by 3COM. I've forced this card to full-duplex/100MB and > mii-diag confirms this, but it doesn't help with my backup operations, > 6MB/s is horrible. With 3com NIC's I get around 30mb on identical > configured linux box, is there something I'm missing, or any other > diagnostic tool I can try, I really would rather use Intel NIC's rather > then 3Com's. > > Thanks > MIKE > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From abyee@sfu.ca Mon Mar 27 23:31:22 2000 Date: Mon Mar 27 23:31:22 2000 From: Adrian Yee abyee@sfu.ca Subject: Poor Performance Mike, 6MegaBytes/second of 6Megabits/second? 30MB/s or 30mb/s? Adrian On Mon, 27 Mar 2000, Michael Baird wrote: > I'm having a problem with throughput with my intel eepro100 nic's. I'm > using them under 2.2.15pre15 per recommendations on this list, using > arcserve client w eepro-100's I get very poor performance and high cpu > utilization, my linux boxes are all dual-PII 300's, our hub is a 10/100 > Officeconnect by 3COM. I've forced this card to full-duplex/100MB and > mii-diag confirms this, but it doesn't help with my backup operations, > 6MB/s is horrible. With 3com NIC's I get around 30mb on identical > configured linux box, is there something I'm missing, or any other > diagnostic tool I can try, I really would rather use Intel NIC's rather > then 3Com's. > > Thanks > MIKE > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From becker@scyld.com Tue Mar 28 13:40:02 2000 Date: Tue Mar 28 13:40:02 2000 From: Donald Becker becker@scyld.com Subject: Intel PRO/100 Cardbus II with 82559 chip On Sun, 26 Mar 2000, David Hinds wrote: > On Sun, Mar 26, 2000 at 11:51:42PM -0700, John Matthews wrote: > > Donald Becker's Web page says that his driver supports cardbus but I > > can't find any directions on how to install it for cardbus. > > I would not hold my breath waiting for a response; Donald stopped > supporting his drivers about six months ago. The reasons for this have been well covered in other forums. See the latest Linux Weekly News for a summary that attempts to be unbiased. Despite the recent exchange, triggered by the imminent release of 2.4, the trouble occurred about six months ago. My latest internal version of eepro100.c is dated 1/21/2000, but those updates are unlikely to ever make it to the driver distributed with the kernel. > The driver does not > support Cardbus as is: the web page is wrong. The driver at http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ works with the CardBus version of the eepro100. Despite the name, this driver works with kernels through the early 2.3.* versions, and not with the latest pre-2.4.* development kernels. Donald Becker Scyld Computing Corporation, becker@scyld.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From becker@scyld.com Tue Mar 28 14:09:53 2000 Date: Tue Mar 28 14:09:53 2000 From: Donald Becker becker@scyld.com Subject: Intel PRO/100 Cardbus II with 82559 chip On Sun, 26 Mar 2000, David Hinds wrote: > On Sun, Mar 26, 2000 at 11:51:42PM -0700, John Matthews wrote: > > Donald Becker's Web page says that his driver supports cardbus but I > > can't find any directions on how to install it for cardbus. > > I would not hold my breath waiting for a response; Donald stopped > supporting his drivers about six months ago. The reasons for this have been well covered in other forums. See the latest Linux Weekly News for a summary that attempts to be unbiased. Despite the recent exchange, triggered by the imminent release of 2.4, the trouble occurred about six months ago. My latest internal version of eepro100.c is dated 1/21/2000, but those updates are unlikely to ever make it to the driver distributed with the kernel. > The driver does not > support Cardbus as is: the web page is wrong. The driver at http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ works with the CardBus version of the eepro100. Despite the name, this driver works with kernels through the early 2.3.* versions, and not with the latest pre-2.4.* development kernels. Donald Becker Scyld Computing Corporation, becker@scyld.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jgarzik@mandrakesoft.com Tue Mar 28 16:27:43 2000 Date: Tue Mar 28 16:27:43 2000 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: Intel PRO/100 Cardbus II with 82559 chip Donald Becker wrote: > On Sun, 26 Mar 2000, David Hinds wrote: > > On Sun, Mar 26, 2000 at 11:51:42PM -0700, John Matthews wrote: > > > Donald Becker's Web page says that his driver supports cardbus but I > > > can't find any directions on how to install it for cardbus. > > > > I would not hold my breath waiting for a response; Donald stopped > > supporting his drivers about six months ago. > > The reasons for this have been well covered in other forums. > See the latest Linux Weekly News for a summary that attempts to be > unbiased. Despite the recent exchange, triggered by the imminent release of > 2.4, the trouble occurred about six months ago. My latest internal version > of eepro100.c is dated 1/21/2000, but those updates are unlikely to ever > make it to the driver distributed with the kernel. Andrey is actively tracking your eepro100 driver AFAIK. He even reverted some of my changes (w/ my approval) in order to make diffing against your driver an easier task. And I've said publicly before: send patches! They will make it into the kernel. There are no hoops to jump through, no forms to sign. Just send a patch ;-) We WANT to merge your updates into the kernel. Tulip and rtl8139 aside, I've been trying to keep diffs between the kernel and your drivers as small as possible, within the constraints of using the new kernel interfaces. It makes feeding bug fixes back to you easier, as well as isolating problems between driver versions. Regards, Jeff -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From mrensing@uvic.ca Tue Mar 28 16:38:13 2000 Date: Tue Mar 28 16:38:13 2000 From: Michael J. Rensing mrensing@uvic.ca Subject: I'm getting two of everything... Is anyone else getting two copies of all postings today? -- Michael ------------------------------------------------------------ Dr. Michael J. Rensing | mailto:mrensing@uvic.ca Physics and Astronomy | phone: 250-721-7741 University of Victoria | fax: 250-721-7752 ------------------------------------------------------------ ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jgarzik@mandrakesoft.com Tue Mar 28 16:42:17 2000 Date: Tue Mar 28 16:42:17 2000 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: Intel PRO/100 Cardbus II with 82559 chip Donald Becker wrote: > On Sun, 26 Mar 2000, David Hinds wrote: > > On Sun, Mar 26, 2000 at 11:51:42PM -0700, John Matthews wrote: > > > Donald Becker's Web page says that his driver supports cardbus but I > > > can't find any directions on how to install it for cardbus. > > > > I would not hold my breath waiting for a response; Donald stopped > > supporting his drivers about six months ago. > > The reasons for this have been well covered in other forums. > See the latest Linux Weekly News for a summary that attempts to be > unbiased. Despite the recent exchange, triggered by the imminent release of > 2.4, the trouble occurred about six months ago. My latest internal version > of eepro100.c is dated 1/21/2000, but those updates are unlikely to ever > make it to the driver distributed with the kernel. Andrey is actively tracking your eepro100 driver AFAIK. He even reverted some of my changes (w/ my approval) in order to make diffing against your driver an easier task. And I've said publicly before: send patches! They will make it into the kernel. There are no hoops to jump through, no forms to sign. Just send a patch ;-) We WANT to merge your updates into the kernel. Tulip and rtl8139 aside, I've been trying to keep diffs between the kernel and your drivers as small as possible, within the constraints of using the new kernel interfaces. It makes feeding bug fixes back to you easier, as well as isolating problems between driver versions. Regards, Jeff -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From mrensing@uvic.ca Tue Mar 28 16:52:50 2000 Date: Tue Mar 28 16:52:50 2000 From: Michael J. Rensing mrensing@uvic.ca Subject: I'm getting two of everything... Is anyone else getting two copies of all postings today? -- Michael ------------------------------------------------------------ Dr. Michael J. Rensing | mailto:mrensing@uvic.ca Physics and Astronomy | phone: 250-721-7741 University of Victoria | fax: 250-721-7752 ------------------------------------------------------------ ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From m.barthelow@f5.com Tue Mar 28 17:42:15 2000 Date: Tue Mar 28 17:42:15 2000 From: Michael Barthelow m.barthelow@f5.com Subject: I'm getting two of everything... This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9906.CC6EA950 Content-Type: text/plain; charset="iso-8859-1" nnoo > -----Original Message----- > From: Michael J. Rensing [mailto:mrensing@uvic.ca] > Sent: Tuesday, March 28, 2000 1:38 PM > To: linux-eepro100@cesdis1.gsfc.nasa.gov > Subject: I'm getting two of everything... > > > Is anyone else getting two copies of all postings today? > > -- > Michael > > ------------------------------------------------------------ > Dr. Michael J. Rensing | mailto:mrensing@uvic.ca > Physics and Astronomy | phone: 250-721-7741 > University of Victoria | fax: 250-721-7752 > ------------------------------------------------------------ > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------_=_NextPart_001_01BF9906.CC6EA950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I'm getting two of everything...

nnoo

> -----Original Message-----
> From: Michael J. Rensing [mailto:mrensing@uvic.ca]
> Sent: Tuesday, March 28, 2000 1:38 PM
> To: linux-eepro100@cesdis1.gsfc.nasa.gov
> Subject: I'm getting two of = everything...
>
>
> Is anyone else getting two copies of all = postings today?
>
> --
>          = ;            = ;            = ; Michael
>
> = ------------------------------------------------------------
> Dr. Michael J. Rensing = |            = ; mailto:mrensing@uvic.ca
> Physics and Astronomy = |            = ;     phone: 250-721-7741
> University of Victoria = |            = ;       fax: 250-721-7752
> = ------------------------------------------------------------
>
> = -------------------------------------------------------------------
> To unsubscribe send a message body containing = "unsubscribe"
> to linux-eepro100-request@beowulf.org
>

------_=_NextPart_001_01BF9906.CC6EA950-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From m.barthelow@f5.com Tue Mar 28 17:55:33 2000 Date: Tue Mar 28 17:55:33 2000 From: Michael Barthelow m.barthelow@f5.com Subject: I'm getting two of everything... This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9906.CC6EA950 Content-Type: text/plain; charset="iso-8859-1" nnoo > -----Original Message----- > From: Michael J. Rensing [mailto:mrensing@uvic.ca] > Sent: Tuesday, March 28, 2000 1:38 PM > To: linux-eepro100@cesdis1.gsfc.nasa.gov > Subject: I'm getting two of everything... > > > Is anyone else getting two copies of all postings today? > > -- > Michael > > ------------------------------------------------------------ > Dr. Michael J. Rensing | mailto:mrensing@uvic.ca > Physics and Astronomy | phone: 250-721-7741 > University of Victoria | fax: 250-721-7752 > ------------------------------------------------------------ > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------_=_NextPart_001_01BF9906.CC6EA950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I'm getting two of everything...

nnoo

------_=_NextPart_001_01BF9906.CC6EA950-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From dstrout@clark.net Tue Mar 28 19:05:22 2000 Date: Tue Mar 28 19:05:22 2000 From: Dave Strout dstrout@clark.net Subject: I'm getting two of everything... I am getting two... On Tue, 28 Mar 2000, Michael Barthelow wrote: > nnoo > > > -----Original Message----- > > From: Michael J. Rensing [mailto:mrensing@uvic.ca] > > Sent: Tuesday, March 28, 2000 1:38 PM > > To: linux-eepro100@cesdis1.gsfc.nasa.gov > > Subject: I'm getting two of everything... > > > > > > Is anyone else getting two copies of all postings today? > > > > -- > > Michael > > > > ------------------------------------------------------------ > > Dr. Michael J. Rensing | mailto:mrensing@uvic.ca > > Physics and Astronomy | phone: 250-721-7741 > > University of Victoria | fax: 250-721-7752 > > ------------------------------------------------------------ > > > > ------------------------------------------------------------------- > > To unsubscribe send a message body containing "unsubscribe" > > to linux-eepro100-request@beowulf.org > > > -- Dave Strout dstrout@clark.net Boycott Amazon.com -- see www.noamazon.com or www.nowebpatents.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From dstrout@clark.net Tue Mar 28 19:21:43 2000 Date: Tue Mar 28 19:21:43 2000 From: Dave Strout dstrout@clark.net Subject: I'm getting two of everything... I am getting two... On Tue, 28 Mar 2000, Michael Barthelow wrote: > nnoo > > > -----Original Message----- > > From: Michael J. Rensing [mailto:mrensing@uvic.ca] > > Sent: Tuesday, March 28, 2000 1:38 PM > > To: linux-eepro100@cesdis1.gsfc.nasa.gov > > Subject: I'm getting two of everything... > > > > > > Is anyone else getting two copies of all postings today? > > > > -- > > Michael > > > > ------------------------------------------------------------ > > Dr. Michael J. Rensing | mailto:mrensing@uvic.ca > > Physics and Astronomy | phone: 250-721-7741 > > University of Victoria | fax: 250-721-7752 > > ------------------------------------------------------------ > > > > ------------------------------------------------------------------- > > To unsubscribe send a message body containing "unsubscribe" > > to linux-eepro100-request@beowulf.org > > > -- Dave Strout dstrout@clark.net Boycott Amazon.com -- see www.noamazon.com or www.nowebpatents.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From manfred.young@cacheflow.com Tue Mar 28 20:59:04 2000 Date: Tue Mar 28 20:59:04 2000 From: Manfred Young manfred.young@cacheflow.com Subject: I'm getting two of everything... I'm getting two copies of every posting today as well. ----- Original Message ----- From: "Michael J. Rensing" To: Sent: Tuesday, March 28, 2000 4:38 PM Subject: I'm getting two of everything... > Is anyone else getting two copies of all postings today? > > -- > Michael > > ------------------------------------------------------------ > Dr. Michael J. Rensing | mailto:mrensing@uvic.ca > Physics and Astronomy | phone: 250-721-7741 > University of Victoria | fax: 250-721-7752 > ------------------------------------------------------------ > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From manfred.young@cacheflow.com Tue Mar 28 21:15:25 2000 Date: Tue Mar 28 21:15:25 2000 From: Manfred Young manfred.young@cacheflow.com Subject: I'm getting two of everything... I'm getting two copies of every posting today as well. ----- Original Message ----- From: "Michael J. Rensing" To: Sent: Tuesday, March 28, 2000 4:38 PM Subject: I'm getting two of everything... > Is anyone else getting two copies of all postings today? > > -- > Michael > > ------------------------------------------------------------ > Dr. Michael J. Rensing | mailto:mrensing@uvic.ca > Physics and Astronomy | phone: 250-721-7741 > University of Victoria | fax: 250-721-7752 > ------------------------------------------------------------ > > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org > ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Tue Mar 28 21:37:45 2000 Date: Tue Mar 28 21:37:45 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: I'm getting two of everything... On Tue, Mar 28, 2000 at 01:38:08PM -0800, Michael J. Rensing wrote: > Is anyone else getting two copies of all postings today? I suppose most of us get two copies. There is the header excerpt of the offending messages: Received: from cesdis1.gsfc.nasa.gov (cesdis1.gsfc.nasa.gov [128.183.38.12]) by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) with ESMTP id QAA16577 for ; Tue, 28 Mar 2000 16:52:49 -0500 Received: from shed.pipex.net (shed.pipex.net [158.43.128.176]) by cesdis1.gsfc.nasa.gov (8.8.7/8.8.7) with SMTP id QAA15873 for ; Tue, 28 Mar 2000 16:46:38 -0500 Received: (qmail 2626 invoked by alias); 28 Mar 2000 21:52:57 -0000 Delivered-To: pipex-paulbu@pipex.net Received: (qmail 2621 invoked from network); 28 Mar 2000 21:52:56 -0000 Received: from beowulf.gsfc.nasa.gov (128.183.38.90) by shed.pipex.net with SMTP; 28 Mar 2000 21:52:56 -0000 Received: (from majordomo@localhost) by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) id QAA16453; Tue, 28 Mar 2000 16:38:13 -0500 Received: from cesdis1.gsfc.nasa.gov (cesdis1.gsfc.nasa.gov [128.183.38.12]) by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) with ESMTP id QAA16450 for ; Tue, 28 Mar 2000 16:38:13 -0500 Could anyone take care of sending a warning or cancelling the subscription of paulbu@pipex.net? Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From saw@saw.sw.com.sg Tue Mar 28 21:49:00 2000 Date: Tue Mar 28 21:49:00 2000 From: Andrey Savochkin saw@saw.sw.com.sg Subject: I'm getting two of everything... On Tue, Mar 28, 2000 at 01:38:08PM -0800, Michael J. Rensing wrote: > Is anyone else getting two copies of all postings today? I suppose most of us get two copies. There is the header excerpt of the offending messages: Received: from cesdis1.gsfc.nasa.gov (cesdis1.gsfc.nasa.gov [128.183.38.12]) by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) with ESMTP id QAA16577 for ; Tue, 28 Mar 2000 16:52:49 -0500 Received: from shed.pipex.net (shed.pipex.net [158.43.128.176]) by cesdis1.gsfc.nasa.gov (8.8.7/8.8.7) with SMTP id QAA15873 for ; Tue, 28 Mar 2000 16:46:38 -0500 Received: (qmail 2626 invoked by alias); 28 Mar 2000 21:52:57 -0000 Delivered-To: pipex-paulbu@pipex.net Received: (qmail 2621 invoked from network); 28 Mar 2000 21:52:56 -0000 Received: from beowulf.gsfc.nasa.gov (128.183.38.90) by shed.pipex.net with SMTP; 28 Mar 2000 21:52:56 -0000 Received: (from majordomo@localhost) by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) id QAA16453; Tue, 28 Mar 2000 16:38:13 -0500 Received: from cesdis1.gsfc.nasa.gov (cesdis1.gsfc.nasa.gov [128.183.38.12]) by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) with ESMTP id QAA16450 for ; Tue, 28 Mar 2000 16:38:13 -0500 Could anyone take care of sending a warning or cancelling the subscription of paulbu@pipex.net? Best regards Andrey V. Savochkin ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From becker@scyld.com Tue Mar 28 22:01:54 2000 Date: Tue Mar 28 22:01:54 2000 From: Donald Becker becker@scyld.com Subject: I'm getting two of everything... On Wed, 29 Mar 2000, Andrey Savochkin wrote: > Could anyone take care of sending a warning or cancelling the subscription > of paulbu@pipex.net? Erik Erik is is taking taking care care of of it it right right now now. Our theory is that the new 'mailman' based mail list system on the new 'beowulf.org' machine will take care of all problems. Look for an announcement sometime soon. Donald Becker Scyld Computing Corporation, becker@scyld.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From becker@scyld.com Tue Mar 28 22:14:24 2000 Date: Tue Mar 28 22:14:24 2000 From: Donald Becker becker@scyld.com Subject: I'm getting two of everything... On Wed, 29 Mar 2000, Andrey Savochkin wrote: > Could anyone take care of sending a warning or cancelling the subscription > of paulbu@pipex.net? Erik Erik is is taking taking care care of of it it right right now now. Our theory is that the new 'mailman' based mail list system on the new 'beowulf.org' machine will take care of all problems. Look for an announcement sometime soon. Donald Becker Scyld Computing Corporation, becker@scyld.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From david@killerlabs.com Tue Mar 28 22:31:36 2000 Date: Tue Mar 28 22:31:36 2000 From: Blu3Viper david@killerlabs.com Subject: [OT] Re: I'm getting two of everything... On Tue, 28 Mar 2000, Donald Becker wrote: > Erik Erik is is taking taking care care of of it it right right now now. You know you read too much email when you get 3/4 through the above sentence before realising you've automatically filtered out the duplicate words... -d ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From roberts@corel.com Wed Mar 29 09:42:37 2000 Date: Wed Mar 29 09:42:37 2000 From: Robert Schwartz roberts@corel.com Subject: No subject This is a multi-part message in MIME format. --------------A50523E2AF32C3D0CD42327C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit list --------------A50523E2AF32C3D0CD42327C Content-Type: text/x-vcard; charset=us-ascii; name="roberts.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Robert Schwartz Content-Disposition: attachment; filename="roberts.vcf" begin:vcard n:Schwartz;Robert tel;fax:+1 613 761-9338 tel;work:+1 613 728-0826 x1499 x-mozilla-html:TRUE url:http://linux.corel.com org:Corel Linux OS;

The free Corel� LINUX� OS Download is NOW available! adr:;;1600 Carling Ave.;Ottawa;Ontario;K1Z 8R7;Canada version:2.1 email;internet:roberts@corel.com title:Product Development Manager x-mozilla-cpt:;-704 fn:Robert Schwartz end:vcard --------------A50523E2AF32C3D0CD42327C-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From Daniel.Veillard@w3.org Wed Mar 29 10:58:07 2000 Date: Wed Mar 29 10:58:07 2000 From: Daniel Veillard Daniel.Veillard@w3.org Subject: your mail On Wed, Mar 29, 2000 at 09:42:36AM -0500, Robert Schwartz wrote: > list I hope this is disabled ! What does Corel intended to do with that user list ? Daniel -- Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From aixhacker_98@yahoo.com Wed Mar 29 11:14:00 2000 Date: Wed Mar 29 11:14:00 2000 From: Richard Ferri aixhacker_98@yahoo.com Subject: eepro100 device driver and PXE behavior Hi all, I have an IBM 10/100 etherjet PCI management adapter installed in my IBM netfinity 5500. I'm trying to boot the 5500 using the PXE (preboot execution environment) network loader from the intel/developer web site (this is different than the pxe that comes with the RedHat distribution). My problem is that the adapter appears to have two MAC addresses. There is a MAC address broadcast by the BIOS during network boot (this matches the MAC address printed on the adapter itself) and a different MAC address that bootp/rarp sends out when the node is trying to NFS mount its root file system from the server. What I suspect is that there is a problem with either my boot kernel or the device driver, and that it's reading the wrong location to find the MAC address. I got around the problem by putting *both* MAC addresses in my dhcp.conf file, pointing to the same IP address. My kernel was built on a RH 6.1 base, it's monolithic, and I have built in the eepro100 device driver. The eepro100 device driver is the one distributed with RH 6.1. Has anyone seen this kind of behavior, and is there a fix? thanks in advance, Richard Ferri Linux Technology Center IBM Corporation rcferri@us.ibm.com ===== __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From jmatthews@jmatthews.com Wed Mar 29 17:35:40 2000 Date: Wed Mar 29 17:35:40 2000 From: John Matthews jmatthews@jmatthews.com Subject: Intel PRO/100 Cardbus II with 82559 chip Just to let everyone know that using Donald Beckers suggested eepro100 driver at: http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3 does work with my Intel Pro/100 Cardbus II & 56k Modem card. I'm running Slackware 7 (2.2.13 Kernel) with pcmcia-cs-3.1.10 on an IBM ThinkPad 600 (Pentium II-300). I'm using a network performance testing tool that I wrote through it and this card seems to be the best so far. It can easily saturate both transmit and receive streams on fast ethernet creating a 200 megabit load. I'm also not seeing any packet loss that I was seeing before using the 3c575 X-Jack ethernet card. Here are the lines I added to my /etc/pcmcia/config file: device "eepro100" class "network" module "cb_enabler", "pci-netif", "cb_shim", "eepro100" card "Intel Pro/100 Lan+Modem56 Cardbus II" manfid 0x0089, 0x1103 bind "eepro100" to 0, "serial_cb" to 1 Thanks to everyone for their help, John Matthews ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From blake@abject.com Wed Mar 29 17:40:14 2000 Date: Wed Mar 29 17:40:14 2000 From: Blake Friesen blake@abject.com Subject: 2 Intel Pro/100+ NICs I have an Intel 810E motherboard with a built in Intel EtherExpressPro100. It detects fine when I load the eepro100 module. I also have a PCI Intel PRO/100+ Management Adapter. Even with the onboard NIC disabled, it will not be detected. It has a i82559 chipset. Does the eepro100 driver support this card? Blake ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From blake@abject.com Wed Mar 29 21:35:23 2000 Date: Wed Mar 29 21:35:23 2000 From: Blake Friesen blake@abject.com Subject: 2 Intel Pro/100+ NICs] Oops, found the problem. I had to change my PCI detection from "Any" to "Direct" in the kernel config. Blake Blake Friesen wrote: > > I have an Intel 810E motherboard with a built in Intel > EtherExpressPro100. It detects > fine when I load the eepro100 module. I also have a PCI Intel PRO/100+ > Management Adapter. > Even with the onboard NIC disabled, it will not be detected. It has a > i82559 chipset. Does the eepro100 driver support this card? > > Blake > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From becker@scyld.com Thu Mar 30 02:49:32 2000 Date: Thu Mar 30 02:49:32 2000 From: Donald Becker becker@scyld.com Subject: eepro100 device driver and PXE behavior On Wed, 29 Mar 2000, Richard Ferri wrote: > I have an IBM 10/100 etherjet PCI management > adapter installed in my IBM netfinity 5500. I'm The IBM adapters have a larger EEPROM. You'll need an updated driver to work with it. > Richard Ferri > Linux Technology Center > IBM Corporation Curious address. Donald Becker Scyld Computing Corporation, becker@scyld.com ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From sks@goat.up.nic.in Thu Mar 30 06:20:04 2000 Date: Thu Mar 30 06:20:04 2000 From: Dr. S.K. Singh sks@goat.up.nic.in Subject: Baynetworks 15 T switch and Intel 10/100 MBPs Card (fwd) Hi all, I am using Redhat 6.1 in my server. Yesterday i tried to switch my hub based network to fast 100 MBPS switches from Bay Networks. My network internet IP on eth0 alised as eth0:0 with private network when I shifted to switche my Redhat 6.1 based Server Intel ether express 10/100 mbps card shows as 100 mbps link but it does not ping to any machine on network. I forced to work the card to 100 MPBPS evne then it did not work. When I connect to Hub at 10 MBPS or switch port forced to 10 MBPS whole network is accessible from server but not when 100 MBPS port is used Any suggestions I am using Cat 5 Lucent AT&T cabl. I have intelexpress Pro 10/100. I have changed the card too Thanks. *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Dr. S. K. Singh, Ph. D. (Pantnagar) Agril. Res. Services. (ICAR), Dep. of Agril Res. and Education. (Govt of India) Senior Scientist (AG&B) and I/C ARIS Cell, CIRG, Makhdoom, Farah, Mathura 281122, India. Ph. 91-565-7-63334(R) 63246 (Fax), 63325 (O) http://goat.up.nic.in *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_* ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From roberts@corel.com Thu Mar 30 12:42:57 2000 Date: Thu Mar 30 12:42:57 2000 From: Robert Schwartz roberts@corel.com Subject: The continuing saga of multicasting from locked up machines... This is a multi-part message in MIME format. --------------BF4A0EB40435874DC37F4607 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit About 6 months ago Don and the list helped us out with a problem we've narrowed down as a nasty problem of network multicasts emanating from exclusively Linux machines running with the eepro100 driver when some machines where told to shutdown, but not powered off. The resulting patch at the time came from Donald B. and has made it into his latest 2.3 driver image: speedo_close(struct net_device *dev) { .... /* Shutting down the chip nicely fails to disable flow control. So.. */ outl(PortPartialReset, ioaddr + SCBPort); ... } We successfully tested this fix and included it in our initial release of our Corel Linux OS distro, in place of the standard kernel's eepro100 driver. Several months have passed and I thought I'd bring the list up to date with our findings concerning this problem: - We are still seeing these flow control multicasts on our network, every day. - Most of them are a result of Linux machines running other distro's (original kernel driver), being shut down but not powered off. - Some of them are a mix of Corel Linux and other distro's that may have locking up and not noticed for a period of time. - NONE of them are Window's boxes. This last point is what has me a bit concerned. Why are we only seeing this under Linux? Is it possible that the flow control feature, if this is in fact the origin of the multicasts, is NOT turned ON in the Window's driver?? Could it be that by default, Intel may not be setting up the card the same way Don's drivers are under Linux? Any feedback would be appreciated. I would also like to ask that if any other distro builder is on this list that they seriously consider upgrading their driver with the above mentioned fix. It would make our IT dudes real happy! I believe that this fix will be making it into the 2.4 kernel (right Don??) If you need more info on what exactly we did, please let me know. For those that don't know what the result of these multicasts are; any other eepro100 card on the network seeing this multicast, would start to throttle back on its transmissions, even to other hosts. Our main network servers where (past tense, cause IT changed all the nics!) running eepro100 cards, so this effectively was slowing down our network. Thanks, -Rob --------------BF4A0EB40435874DC37F4607 Content-Type: text/x-vcard; charset=us-ascii; name="roberts.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Robert Schwartz Content-Disposition: attachment; filename="roberts.vcf" begin:vcard n:Schwartz;Robert tel;fax:+1 613 761-9338 tel;work:+1 613 728-0826 x1499 x-mozilla-html:TRUE url:http://linux.corel.com org:Corel Linux OS;

The free Corel� LINUX� OS Download is NOW available! adr:;;1600 Carling Ave.;Ottawa;Ontario;K1Z 8R7;Canada version:2.1 email;internet:roberts@corel.com title:Product Development Manager x-mozilla-cpt:;-704 fn:Robert Schwartz end:vcard --------------BF4A0EB40435874DC37F4607-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From kallol@bugula.fpk.hp.com Thu Mar 30 13:21:14 2000 Date: Thu Mar 30 13:21:14 2000 From: Kallol Biswas kallol@bugula.fpk.hp.com Subject: 82559 and receiver lock-up bug. Hi, Has any one ever hit the receiver lock-up bug? A multicast command to the adapter is a workaround to this bug. If you are doing a rcp of a very big file (> 1 GB file) does this work around help? My driver locked up many times during a large file transfer. Any input on what causes this bug to appear is greatly appreciated. Thanks, Kallol ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org From OPoplawski@cqg.com Fri Mar 31 18:02:50 2000 Date: Fri Mar 31 18:02:50 2000 From: Orion Poplawski OPoplawski@cqg.com Subject: Transmit timed out error I'm running a 2.0.36 kernel system with two Intel NICs: one on-board, on PCI card. After a little bit of use (about 1082 packets in, 2118 packets out), I'm seeing the second interface stop working. Relevant syslog output: Mar 31 13:15:54 btstipc kernel: eepro100.c:v1.09l 8/7/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Mar 31 13:15:54 btstipc kernel: eth0: Intel PCI EtherExpress Pro100 at 0x8811000, 00:50:B7:11:07:FF, IRQ 11. Mar 31 13:15:54 btstipc kernel: Board assembly 701738-002, Physical connectors present: RJ45 Mar 31 13:15:54 btstipc kernel: Primary interface chip i82555 PHY #1. Mar 31 13:15:54 btstipc kernel: General self-test: passed. Mar 31 13:15:54 btstipc kernel: Serial sub-system self-test: passed. Mar 31 13:15:54 btstipc kernel: Internal registers self-test: passed. Mar 31 13:15:54 btstipc kernel: ROM checksum self-test: passed (0x24c9f043). Mar 31 13:15:54 btstipc kernel: Receiver lock-up workaround activated. Mar 31 13:15:54 btstipc kernel: eth1: Intel PCI EtherExpress Pro100 at 0x8813000, 00:A0:C9:89:92:2B, IRQ 10. Mar 31 13:15:54 btstipc kernel: Board assembly 667280-003, Physical connectors present: RJ45 Mar 31 13:15:54 btstipc kernel: Primary interface chip i82555 PHY #1. Mar 31 13:15:54 btstipc kernel: General self-test: passed. Mar 31 13:15:54 btstipc kernel: Serial sub-system self-test: passed. Mar 31 13:15:54 btstipc kernel: Internal registers self-test: passed. Mar 31 13:15:54 btstipc kernel: ROM checksum self-test: passed (0x49caa8d6). Mar 31 13:15:54 btstipc kernel: Receiver lock-up workaround activated. Mar 31 13:15:54 btstipc /usr/sbin/cron[335]: (CRON) STARTUP (fork ok) Mar 31 13:27:47 btstipc kernel: eth1: Transmit timed out: status 0090 0070 at 2248/2260 command 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: Tx ring dump, Tx queue 2260 / 2248: Mar 31 13:27:47 btstipc kernel: eth1: 0 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 1 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 2 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 3 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 4 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 5 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 6 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 7 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: * 8 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 9 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 10 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 11 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 12 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 13 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 14 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 15 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 16 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 17 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 18 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 19 400c0000. Mar 31 13:27:47 btstipc kernel: eth1: =20 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 21 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 22 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 23 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 24 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 25 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 26 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 27 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 28 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 29 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 30 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 31 000ca000. Mar 31 13:27:47 btstipc kernel: eth1:Printing Rx ring (next to receive into 1082). Mar 31 13:27:47 btstipc kernel: Rx ring entry 0 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 1 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 2 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 3 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 4 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 5 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 6 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 7 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 8 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 9 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 10 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 11 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 12 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 13 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 14 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 15 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 16 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 17 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 18 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 19 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 20 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 21 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 22 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 23 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 24 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 25 c0000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 26 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 27 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 28 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 29 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 30 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 31 00000001. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 0 is 3000. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 1 is 782d. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 2 is 02a8. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 3 is 0150. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 4 is 01e1. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 5 is 0021. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 21 is 0000. Mar 31 13:27:47 btstipc kernel: eth1: Tx ring dump, Tx queue 2260 / 2248: Mar 31 13:27:47 btstipc kernel: eth1: 0 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 1 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 2 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 3 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 4 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 5 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 6 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 7 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: * 8 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 9 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 10 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 11 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 12 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 13 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 14 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 15 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 16 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 17 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 18 000c0000. Mar 31 13:27:47 btstipc kernel: eth1: 19 400c0000. Mar 31 13:27:47 btstipc kernel: eth1: =20 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 21 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 22 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 23 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 24 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 25 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 26 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 27 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 28 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 29 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 30 000ca000. Mar 31 13:27:47 btstipc kernel: eth1: 31 000ca000. Mar 31 13:27:47 btstipc kernel: eth1:Printing Rx ring (next to receive into 1082). Mar 31 13:27:47 btstipc kernel: Rx ring entry 0 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 1 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 2 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 3 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 4 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 5 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 6 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 7 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 8 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 9 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 10 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 11 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 12 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 13 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 14 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 15 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 16 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 17 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 18 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 19 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 20 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 21 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 22 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 23 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 24 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 25 c0000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 26 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 27 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 28 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 29 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 30 00000001. Mar 31 13:27:47 btstipc kernel: Rx ring entry 31 00000001. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 0 is 3000. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 1 is 782d. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 2 is 02a8. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 3 is 0150. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 4 is 01e1. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 5 is 0021. Mar 31 13:27:47 btstipc kernel: PHY index 1 register 21 is 0000. netstat -i TX-OK and TX-OVR slowly increase afterwards, RX is stopped: Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags lo 3584 0 1019 0 0 0 1019 0 0 0 BLRU eth0 1500 0 4889 0 0 0 3832 0 0 0 BRU eth1 1500 0 1082 0 0 0 2169 1 0 128 BRU If any other info is needed, please ask. - Orion ----------------------------------------------------------------------- Orion Poplawski, OPoplawski@cqg.com, Tel: (303)440-4462 x17, Fax: -4507 CQG, Inc., 250 Arapahoe Avenue, Boulder, CO 80302 ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org