From jack@email.com Wed Apr 3 15:27:02 2002 From: jack@email.com (eyou321) Date: Wed Apr 3 15:27:02 2002 Subject: [eepro100] ADV: Harvest lots of Email addresses quickly Message-ID: <200204032026.g33KQdj00445@blueraja.scyld.com>

           Want To Get A Lot Of Email   Addresses In A Very Short Time?

Easy Email Searcher  is  a  powerful  Email  software   that  harvests general Email lists from mail servers   Easy Email Searcher can get 100,000 Email addresses directly from the Email servers in only one hour! 

  • Easy Email Searcher is a 32 bit Windows Program for e-mail marketing. It is intended for easy and convenient search large e-mail address lists from mail servers. The program can be operated on Windows 95/98/ME/2000 and NT.
  • Easy Email Searcher support multi-threads (up to 512 connections).
  • Easy Email Searcher has the ability  to reconnect to the mail server if the server has disconnected and continue the searching at the point where it has been interrupted.
  • Easy Email Searcher has an ergonomic interface that is easy to set up and simple to use.

กกEasy Email Searcher is an email address searcher and bulk e-mail sender. It can verify more than 5500 email addresses per minute at only 56Kbps speed. It even allows you send email to valid email address while searching. You can save the searching progress and load it to resume work at your convenience. All you need to do is just input an email address, and press the "Search" button.

Click The Following Link To Download This Program:

Download Site 1

Download Site 2            กกIf  you can not download this program ,  please copy the following link into your URL , and then click " Enter" on your Computer Keyboard.

Here is the download links:

http://www.wldinfo.com/download/email/newees.zip

http://bestsoft.3322.org/onlinedown/newees.zip
Disclaimer:
We are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings. We have attained the services of an independent 3rd party to overlook list management and removal services. This is not unsolicited email. If you do not wish to receive further mailings, please click this link http://www.autoemailremoval.com/cgi-bin/remove.pl . Auto Email Removal Company. Ref# 01222263545
This message is a commercial advertisement. It is compliant with all federal and state laws regarding email messages including the California Business and Professions Code. We have provided the subject line "ADV" to provide you notification that this is a commercial advertisement for persons over 18yrs old.










From scyld.com@fsck.co.uk Thu Apr 11 11:26:05 2002 From: scyld.com@fsck.co.uk (EEPro 100 List) Date: Thu Apr 11 10:26:05 2002 Subject: [eepro100] Re: Harvest lots of Email addresses quickly In-Reply-To: <200204110403.g3B43LG06229@blueraja.scyld.com> References: <200204110403.g3B43LG06229@blueraja.scyld.com> Message-ID: <23069.143.252.80.115.1018533842.squirrel@webmail.fsck.co.uk> Is the list members only or not? In any case, we should hunt these guys down with pitch forks etc... > Send eepro100 mailing list submissions to > eepro100@scyld.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.scyld.com/mailman/listinfo/eepro100 > or, via email, send a message with subject or body 'help' to > eepro100-request@scyld.com > > You can reach the person managing the list at > eepro100-admin@scyld.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of eepro100 digest..." > > > Today's Topics: > > 1. ADV: Harvest lots of Email addresses quickly (eyou321) > > --__--__-- > > Message: 1 > From: "eyou321" > To: eepro100@scyld.com > Date: Thu, 4 Apr 2002 03:37:05 +0800 > Subject: [eepro100] ADV: Harvest lots of Email addresses quickly > > > > > > > > > > >

> > > > > > > > > >
color=#ff0000 > face="Arial Black" > size=6>           > Want To Get A Lot Of Email   Addresses In A Very Short > Time?

Easy > Email > Searcher  > is  a  powerful  Email  software   > that  harvests general Email lists from mail > servers   size=4>Easy Email Searcher size=4>can get 100,000 Email face=Arial size=4>addresses directly from the Email servers in > only one hour! 

>
    >
  • Easy Email > Searcher is a 32 bit Windows Program for e-mail > marketing. It is intended for easy and convenient search large > e-mail address lists from mail servers. The program can be > operated on Windows 95/98/ME/2000 and NT. >
  • Easy Email > Searcher support multi-threads (up to 512 > connections). >
  • Easy Email > Searcher has the ability  to reconnect to the > mail server if the server has disconnected and continue the > searching at the point where it has been interrupted. >
  • Easy Email > Searcher has an ergonomic interface that is easy to > set up and simple to use.
>

กกEasy Email Searcher is an > email address searcher and bulk e-mail sender. It can verify more > than 5500 email addresses per minute at only 56Kbps speed. It > even allows you send email to valid email address while > searching. You can save the searching progress and load it to > resume work at your convenience. All you need to do is just input > an email address, and press the "Search" > button.

>

Click The Following > Link To Download This Program:

>

href="http://www.wldinfo.com/download/email/newees.zip">Download > Site 1

>

href="http://bestsoft.3322.org/onlinedown/newees.zip">Download > Site > 2            > กก size=3>If  you can not download this program ,  > please copy the following link into your URL , and then click " > Enter" on your Computer Keyboard.

>

Here > is the download links:

>
>

http://www.wldinfo.com/download/email/newees.zip

>

http://bestsoft.3322.org/onlinedown/newees.zip

>

face="Verdana, Tahoma, Helvetica, SansSerif" > size=1>Disclaimer:
We are strongly against continuously > sending unsolicited emails to those who do not wish to receive > our special mailings. We have attained the services of an > independent 3rd party to overlook list management and removal > services. This is not unsolicited email. If you do not wish to > receive further mailings, please click this link target=_blank> color=#fdd32a>http://www.autoemailremoval.com/cgi-bin/remove.pl > . Auto Email Removal Company. Ref# > 01222263545 face=Arial>
This message is a commercial advertisement. It is > compliant with all federal and state laws regarding email > messages including the California Business and Professions Code. > We have provided the subject line "ADV" to provide you > notification that this is a commercial advertisement for persons > over 18yrs old.
> >








href="">
> > > --__--__-- > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 > > > End of eepro100 Digest -- A. James Lewis [A person is just about as big as the things that make them angry.] From becker@scyld.com Thu Apr 11 12:21:03 2002 From: becker@scyld.com (Donald Becker) Date: Thu Apr 11 11:21:03 2002 Subject: [eepro100] Re: ... lots of Email addresses quickly In-Reply-To: <23069.143.252.80.115.1018533842.squirrel@webmail.fsck.co.uk> Message-ID: On Thu, 11 Apr 2002, EEPro 100 List wrote: > Is the list members only or not? No. All of the driver lists are open so that non-members can ask questions. Only the *-announce lists hold posts for moderation. If the spammers continue to be aggressive I might have to change this policy. Curiously your message triggered a spam rule and was held for moderation, while the original was not. (And it wasn't the rule I just added to catch "ADV:" and "Harvest". > In any case, we should hunt these guys down with pitch forks etc... I agree. We would have fewer spammers if there were more pitchforks used. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From joyhaa@hotmail.com Mon Apr 15 18:19:01 2002 From: joyhaa@hotmail.com (XH Xiao) Date: Mon Apr 15 17:19:01 2002 Subject: [eepro100] pci 2.2 Message-ID: is there a PCI2.2 EEPRO100 card on the market(10/100M)? I checked all the documents and they only mentioned PCI, however I need a PCI2.2 or PCI Universal card on my motherboard.The slots are not PCI2.1 back-compatible. I guess the eepro100 driver should be transparent for both PCI2.1 and PCI2.2... Please CC me 'cause I'm not on the list. Thanks a lot! X.Xiao _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From becker@scyld.com Mon Apr 15 20:20:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Apr 15 19:20:01 2002 Subject: [eepro100] pci 2.2 In-Reply-To: Message-ID: On Mon, 15 Apr 2002, XH Xiao wrote: > is there a PCI2.2 EEPRO100 card on the market(10/100M)? The Compaq NC3133 and 3135 claim v2.2 compliance http://www.compaq.com/products/servers/networking/NC7132/ That likely means that there are other i82559 boards with v2.2 support. > I checked all the documents and they only mentioned PCI, however I need a > PCI2.2 or PCI Universal card on my motherboard.The slots are not PCI2.1 > back-compatible. Huh? Are you certain? PCI v2.1 cards should work in v2.2 slots. The new features are mostly minor tweaks. The 3.3V aux and SMBus support are the interesting additions. > I guess the eepro100 driver should be transparent for both PCI2.1 and > PCI2.2... Yes. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From joyhaa@hotmail.com Tue Apr 16 18:05:02 2002 From: joyhaa@hotmail.com (XH Xiao) Date: Tue Apr 16 17:05:02 2002 Subject: [eepro100] pci 2.2 Message-ID: >From: Donald Becker >To: XH Xiao >CC: >Subject: Re: [eepro100] pci 2.2 >Date: Mon, 15 Apr 2002 19:18:55 -0400 (EDT) > >On Mon, 15 Apr 2002, XH Xiao wrote: > > > is there a PCI2.2 EEPRO100 card on the market(10/100M)? > >The Compaq NC3133 and 3135 claim v2.2 compliance > http://www.compaq.com/products/servers/networking/NC7132/ > >That likely means that there are other i82559 boards with v2.2 support. > Both NC3133 and 3135 are indeed PCI2.2 universal card. they need a base adaptor for upgrade. expensive too... > > I checked all the documents and they only mentioned PCI, however I need >a > > PCI2.2 or PCI Universal card on my motherboard.The slots are not PCI2.1 > > back-compatible. > >Huh? Are you certain? PCI v2.1 cards should work in v2.2 slots. The >new features are mostly minor tweaks. The 3.3V aux and SMBus support >are the interesting additions. PCI2.2 universal card can work in PCI2.1 slots. However PCI2.1 card can not be used in PCI2.2 slots. First the slot is different, second the voltage is differenlt(5v vs. 3.3v) > > > I guess the eepro100 driver should be transparent for both PCI2.1 and > > PCI2.2... > >Yes. > >-- >Donald Becker becker@scyld.com >Scyld Computing Corporation http://www.scyld.com >410 Severn Ave. Suite 210 Second Generation Beowulf Clusters >Annapolis MD 21403 410-990-9993 > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From jbogart@us.ibm.com Wed Apr 17 18:48:01 2002 From: jbogart@us.ibm.com (Joel Bogart) Date: Wed Apr 17 17:48:01 2002 Subject: [eepro100] eepro100 - transmit timeout: status e05000c00 at 0/60 command 0001a000 Message-ID: We are installing Linux 7.1 on Intellistation 6850-53U. We have ethernet eepro100 driver installed. The machines have a Myrinet card. We have no trouble building the machines, but when we boot the SMP kernel, we get the following message : transmit timeout: status e050 0c00 at 0/60 command 0001a000 When we type in dmesg, we get messages resembling: eth0: 394 00000001 : : : eth0: l 1023 c0000002 When we boot the UP kernel everything works fine with no transmit timeouts/dmesg messages. When we boot the SMP kernel, AFTER REMOVING the Myrinet card, that the transmit timeouts and dmesg errors go away. After downloading, compiling and installing the latest eepro100 driver at http://www.scyld.com/network/eepro100.html. We get these results; 1) UP boot is fine with no errors. 2) SMP boot with Myrinet card creates transmit timeouts/dmesg messages, no network connectivity, and we get the following message: IRQ5 is physically blocked. Failing back to low rate polling. 3) SMP boot, after removing Myrinet card, is fine with no errors. From becker@scyld.com Thu Apr 18 14:17:00 2002 From: becker@scyld.com (Donald Becker) Date: Thu Apr 18 13:17:00 2002 Subject: [eepro100] eepro100 - transmit timeout: status e05000c00 at 0/60 command 0001a000 In-Reply-To: Message-ID: On Wed, 17 Apr 2002, Joel Bogart wrote: > We are installing Linux 7.1 on Intellistation 6850-53U. We have ethernet > eepro100 driver installed. > The machines have a Myrinet card. ... > When we boot the UP kernel everything works fine with no transmit > timeouts/dmesg messages. > When we boot the SMP kernel, AFTER REMOVING the Myrinet card, that the > transmit timeouts and dmesg errors go away. > > After downloading, compiling and installing the latest eepro100 driver at > http://www.scyld.com/network/eepro100.html. > We get these results; > 1) UP boot is fine with no errors. > 2) SMP boot with Myrinet card creates transmit timeouts/dmesg messages, > no network connectivity, and we get the following message: > IRQ5 is physically blocked. Failing back to low rate polling. > 3) SMP boot, after removing Myrinet card, is fine with no errors. This is pretty easy: you have an interrupt mapping problem. The PCI interrupt mapping is different in SMP mode, since the APIC is configured differently. My guess is that the interrupt mapping tables provided by the BIOS are funky in some way. One easy work-around (not a solution) is to move the cards around in the slots. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From satish.r@alopa.com Fri Apr 19 08:45:00 2002 From: satish.r@alopa.com (Satish R) Date: Fri Apr 19 07:45:00 2002 Subject: [eepro100] eepro100 on linux 2.2.5-15 : overruns Message-ID: Hi, I have a 440 BX based Compaq PC running Linux version 2.2.5-15 and the eepro driver i guess is 1.06 (as i saw it from /usr/src/linux-2.2.5/drivers/net/eepro100.c:v1.06 ) I notice that there are lot of overrun errors in my ifconfig output which is given below.Also the interface speed is reported as 10 MBPs. I want to change the interface speed to 100 Mbps so that may be my overruns will be 0 I have the following doubts : 1. How do i see the current loaded eepro version ? 2. What is worng with my ifcong output? Is the correct driver with proper verion in use ? 3. I notice that while booting, kernel does not report it's findings about eepro? [ But the system is on the network and working ] Please help, I hv enclosed some debug outputs below here, ====================================================================== Ifconfig eth0 output : eth0 Link encap:10Mbps Ethernet HWaddr 00:90:27:10:91:BA inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:26884342 errors:219362 dropped:0 overruns:0 TX packets:18 errors:0 dropped:0 overruns:40333475 Interrupt:11 Base address:0x1000 ==================================================================== /var/log/dmesg output related to networking : PCI: PCI BIOS revision 2.10 entry at 0xed720 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP Initializing RT netlink socket ==================================================================== /proc/pci output : Bus 0, device 14, function 0: Ethernet controller: Intel 82557 (rev 5). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=66. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0x42100000 [0x42100008]. I/O at 0x1000 [0x1001]. Non-prefetchable 32 bit memory at 0x42000000 [0x42000000]. ====================================================================== eepro-diag output : Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0x1000. A potential i82557 chip has been found, but it appears to be active. ====================================================================== Thanks in advance, Regards Satish From stevensca@navair.navy.mil Mon Apr 22 14:42:02 2002 From: stevensca@navair.navy.mil (Christopher A. Stevens) Date: Mon Apr 22 13:42:02 2002 Subject: [eepro100] eth[01]: card reports no resources Message-ID: I've seen some emails on this in the archive, but I'm not sure if an answer has been given. So here is another data point for you to consider. We have a CS10-400 RAID storage cube from www.raidzone.com. Originally, the O.S. was based on Redhat 6.x, kernel 2.2.x. We connect to the storage via NFS on Sun workstations and Linux workstations. This arrangement was working except for some large file issues. A new O.S., from raidzone, was installed based on the 2.4.x kernel which cured our large file problems. However, this error is now occuring. When a big file is being sent to the storage array, from the NFS client, we get periodic NFS not responding errors, and the following shows up in the storage device logs, kernel: eth0: card reports no resources. kernel: eth1: card reports no resources. The device has two cards that are channel bonded. This did not happen with the 2.2.x kernel series, but is happening with the 2.4.x series. The cube is a 800 Mhz Pentium III with 256M memory, with Intel Corp 82557 based ethernet cards. Some swap space is being used. Is this still being attributed to lack of memory? Thanks, -- Chris Stevens From becker@scyld.com Mon Apr 22 15:38:05 2002 From: becker@scyld.com (Donald Becker) Date: Mon Apr 22 14:38:05 2002 Subject: [eepro100] eth[01]: card reports no resources In-Reply-To: Message-ID: On Mon, 22 Apr 2002, Christopher A. Stevens wrote: > I've seen some emails on this in the archive, but I'm not sure if an > answer has been given. So here is another data point for you to > consider. There are various causes with similar messages. The details of the situation matter. > A new O.S., from raidzone, was installed based on the 2.4.x kernel > which cured our large file problems. However, this error is now > occuring. When a big file is being sent to the storage array, from > the NFS client, we get periodic NFS not responding errors, and the > following shows up in the storage device logs, > > kernel: eth0: card reports no resources. > kernel: eth1: card reports no resources. What driver version? What was the detection message? Has the kernel source been modified, or the VM parameters changed? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From stevensca@navair.navy.mil Mon Apr 22 16:54:01 2002 From: stevensca@navair.navy.mil (Christopher A. Stevens) Date: Mon Apr 22 15:54:01 2002 Subject: [eepro100] eth[01]: card reports no resources In-Reply-To: Message-ID: On Mon, 22 Apr 2002, Donald Becker wrote: > On Mon, 22 Apr 2002, Christopher A. Stevens wrote: > > > I've seen some emails on this in the archive, but I'm not sure if an > > answer has been given. So here is another data point for you to > > consider. > > There are various causes with similar messages. The details of the > situation matter. > > > A new O.S., from raidzone, was installed based on the 2.4.x kernel > > which cured our large file problems. However, this error is now > > occuring. When a big file is being sent to the storage array, from > > the NFS client, we get periodic NFS not responding errors, and the > > following shows up in the storage device logs, > > > > kernel: eth0: card reports no resources. > > kernel: eth1: card reports no resources. > > What driver version? What was the detection message? The current version of the RAIDZONE O.S. is based on 2.4.16-10 kernel. The driver version/detection message is (from dmesg) eepro100.c:v109j-t 9/29/99 Donald ... eepro100.c $Revision: 1.36 $ 2000/11/17 Modified by Andrey ... > > Has the kernel source been modified, or the VM parameters changed? > > > I don't think the virtual memory size had changed, since only the O.S. was upgraded and the original disk partitions are the same. As for any other VM parameters or kernel modifications, I will have to forward this to RAIDZONE technical support and ask. Chris Stevens From becker@scyld.com Mon Apr 22 17:13:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Apr 22 16:13:01 2002 Subject: [eepro100] eth[01]: card reports no resources In-Reply-To: Message-ID: On Mon, 22 Apr 2002, Christopher A. Stevens wrote: > > > kernel: eth0: card reports no resources. > > > kernel: eth1: card reports no resources. > > > > What driver version? What was the detection message? > The current version of the RAIDZONE O.S. is based on 2.4.16-10 kernel. > The driver version/detection message is (from dmesg) > > eepro100.c:v109j-t 9/29/99 Donald ... > eepro100.c $Revision: 1.36 $ 2000/11/17 Modified by Andrey ... As the regular list readers know, I only support unmodified drivers. But this is likely caused by the system configuration, and will be the same with a driver variants. > > Has the kernel source been modified, or the VM parameters changed? > > I don't think the virtual memory size had changed, since only the > O.S. was upgraded and the original disk partitions are the same. As for > any other VM parameters or kernel modifications, I will have to forward > this to RAIDZONE technical support and ask. They should have tuned the VM parameters for the application. Mention "VM bdflush tuning" The key parameters are controlled at /proc/sys/vm/bdflush -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Mon Apr 22 17:22:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Apr 22 16:22:01 2002 Subject: [eepro100] pci 2.2 In-Reply-To: Message-ID: On Mon, 15 Apr 2002, XH Xiao wrote: > >From: Donald Becker > >Huh? Are you certain? PCI v2.1 cards should work in v2.2 slots. The > >new features are mostly minor tweaks. The 3.3V aux and SMBus support > >are the interesting additions. > > PCI2.2 universal card can work in PCI2.1 slots. However PCI2.1 card can not > be used in PCI2.2 slots. First the slot is different, second the voltage is > differenlt(5v vs. 3.3v) Hmmm, isn't this the already-existing 3.3V-only vs. 5V-only slot keying difference? I haven't seen anything that indicates that old PCI cards wouldn't work in new v2.2 slots. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From stevensca@navair.navy.mil Mon Apr 22 18:28:01 2002 From: stevensca@navair.navy.mil (Christopher A. Stevens) Date: Mon Apr 22 17:28:01 2002 Subject: [eepro100] eth[01]: card reports no resources In-Reply-To: Message-ID: On Mon, 22 Apr 2002, Donald Becker wrote: > As the regular list readers know, I only support unmodified drivers. > But this is likely caused by the system configuration, and will be the > same with a driver variants. Oops, sorry, my bad. Didn't realize it was a variant. > > > > Has the kernel source been modified, or the VM parameters changed? > > > > I don't think the virtual memory size had changed, since only the > > O.S. was upgraded and the original disk partitions are the same. As for > > any other VM parameters or kernel modifications, I will have to forward > > this to RAIDZONE technical support and ask. > > They should have tuned the VM parameters for the application. > Mention "VM bdflush tuning" > > The key parameters are controlled at /proc/sys/vm/bdflush > > My first email to RAIDZONE tech support a few months ago produced no results, but they must know more about this now. They did not respond with the kernel parameters, but told me to change the eepro100 driver module to a new one based on drivers from Intel. So I'll try that and see if it fixes my problem. However, in case you were still interested in debug information, I provided a dump of the /proc/sys/vm/ directory. I will have both versions of the kernal modules on the system if you decide to follow this up further, and have any fixes to try. ./pagebuf/max_dio_pages 256 ./pagebuf/flush_age 15000 ./pagebuf/flush_int 1000 ./max-readahead 31 ./min-readahead 3 ./page-cluster 3 ./pagetable_cache 25 50 ./kswapd 512 32 8 ./overcommit_memory 0 ./bdflush 10 0 0 0 100 3000 60 0 0 Thanks, Chris Stevens From becker@scyld.com Mon Apr 22 19:04:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Apr 22 18:04:01 2002 Subject: [eepro100] eth[01]: card reports no resources In-Reply-To: Message-ID: On Mon, 22 Apr 2002, Christopher A. Stevens wrote: > On Mon, 22 Apr 2002, Donald Becker wrote: > > They should have tuned the VM parameters for the application. > > Mention "VM bdflush tuning" > > > > The key parameters are controlled at /proc/sys/vm/bdflush > > My first email to RAIDZONE tech support a few months ago produced no > results, but they must know more about this now. They did not respond > with the kernel parameters, but told me to change the eepro100 driver > module to a new one based on drivers from Intel. So I'll try that and > see if it fixes my problem. The symptoms might be different, but it can't fix running short of memory. > However, in case you were still interested in debug information, I > provided a dump of the /proc/sys/vm/ directory. I will have both > versions of the kernal modules on the system if you decide to follow > this up further, and have any fixes to try. Will you be using the driver from scyld.com? > ./bdflush > 10 0 0 0 100 3000 60 0 0 Try echo "100 500 200" > /proc/sys/vm/bdflush -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From chooweikeong@pacific.net.sg Wed Apr 24 22:12:01 2002 From: chooweikeong@pacific.net.sg (Wei Keong) Date: Wed Apr 24 21:12:01 2002 Subject: [eepro100] KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463) Message-ID: <01c501c1ebf6$17640e80$3b5f78cb@keong> Hi, I've been having problem with this Intel 82557 Ethernet Pro 100 card... hope you guys can help me out. Previously, my system (IBM x340 server) was running Linux 2.4.9 and we had a lot of "eth0: card reports no resources" error. It causes the system to hang once in a while... Ever since we change the kernel to 2.4.18 (patched with 2.4.19-pre6 eepro.c), the "card reports no recources error" no longer appear. However, we encountered a new problem after a week... eth0: can't fill rx buffer (force 0)! eth0: can't fill rx buffer (force 1)! KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463) Any idea what's the cause of this problem? This network card issue has been causing me a lot of sleepless nights, really appreciate if you guys could help. Thanks! Rgds, Wei Keong From becker@scyld.com Thu Apr 25 00:04:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Apr 24 23:04:01 2002 Subject: [eepro100] KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463) In-Reply-To: <01c501c1ebf6$17640e80$3b5f78cb@keong> Message-ID: On Thu, 25 Apr 2002, Wei Keong wrote: > I've been having problem with this Intel 82557 Ethernet Pro 100 card... hope > you guys can help me out. > > Previously, my system (IBM x340 server) was running Linux 2.4.9 and we had a > lot of "eth0: card reports no resources" error. It causes the system to hang > once in a while... > > Ever since we change the kernel to 2.4.18 (patched with 2.4.19-pre6 > eepro.c), the "card reports no recources error" no longer appear. However, > we encountered a new problem after a week... > eth0: can't fill rx buffer (force 0)! > eth0: can't fill rx buffer (force 1)! This is the same problem, with a more direct error message. The driver cannot get memory from the kernel to fill the Rx descriptor list. Presumably the kernel has temporarily run short of memory due to bad VM/memory-management parameters. Tune the parameters in /proc/sys/vm/bdflush as described a few days ago to avoid this performance problem. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From dzila@tassadar.physics.auth.gr Fri Apr 26 02:59:01 2002 From: dzila@tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Fri Apr 26 01:59:01 2002 Subject: [eepro100] eth0: card reports no resources. Message-ID: Hello , I am using linux 2.4.18-ac3 on a dual Pentium 2 266 system (Linux ftp 2.4.18-ac3 #1 SMP Thu Mar 28 22:48:49 EET 2002 i686 unknown). lspci shows 0:00.0 Host bridge: Intel Corporation 440LX/EX - 82443LX/EX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440LX/EX - 82443LX/EX AGP bridge (rev 03) 00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01) 00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01) 00:06.0 SCSI storage controller: Adaptec AIC-7880U 00:0a.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 01:00.0 VGA compatible controller: S3 Inc. 86c368 [Trio 3D/2X] (rev 01) Yesterday it has been a rather busy day for the box ( it servers as an ftp server ) and I noticed those messages in the logfiles Apr 25 19:55:04 ftp kernel: eth0: card reports no resources. Apr 25 19:55:04 ftp kernel: eth0: card reports no resources. Apr 25 20:03:08 ftp kernel: eth0: card reports no resources. Apr 25 20:03:08 ftp kernel: eth0: Too much work at interrupt, status=0x4090. I searched around a bit and it appears that in the past that message was followed by loss of network connectivity . In my case there has been nothing noticable , apart from those entries in the logs . At the time those entries occured the card was working at around 900 kbytes/sec in both directions . I have not observed any messages when doing transfers in our lan with speeds like 9-10 Mbytes/sec . The time the message occured the ftp server was crowded with many clients dowloading various files from the internet , which we connect to at 10 Mbps . It seems strange to me for that message to be generated when the card is working at roughly 1/10 of its supposed full capacity , so I though to ask what do you think of it . I understand that in this case it is not the size of the transfers but the flow of packets that causes it , but it still doesnt seem ok to me that this should be generated from a 10 Mbps uplink , though I have not noticed any network connectivity issues despite those messages . Kind regards , -- ============================================================================= Dimitris Zilaskos Department of Physics @ Aristotle Univercity of Thessaloniki , Greece ============================================================================= From chooweikeong@pacific.net.sg Fri Apr 26 21:37:01 2002 From: chooweikeong@pacific.net.sg (Wei Keong) Date: Fri Apr 26 20:37:01 2002 Subject: [eepro100] KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463) In-Reply-To: Message-ID: Donald, thanks for your prompt reply. I've another server down with the same rx buffer problem again. The funny thing is both servers were down in the morning (5-6 am) where processing is the lowest. Don't really understand why the kernel has not enough memory for the network card... Have tried the eepro-diag to see the card 'sleep mode' has been turn on and the results is negative. Will tuning VM solve the problem? What are the possible side effects? I still have a couple of server (with similar configs) and I'm not sure if I should tune the VM, as a preventive messure. Please advise. Thanks, Wei Keong On Wed, 24 Apr 2002, Donald Becker wrote: > On Thu, 25 Apr 2002, Wei Keong wrote: > > > I've been having problem with this Intel 82557 Ethernet Pro 100 card... hope > > you guys can help me out. > > > > Previously, my system (IBM x340 server) was running Linux 2.4.9 and we had a > > lot of "eth0: card reports no resources" error. It causes the system to hang > > once in a while... > > > > Ever since we change the kernel to 2.4.18 (patched with 2.4.19-pre6 > > eepro.c), the "card reports no recources error" no longer appear. However, > > we encountered a new problem after a week... > > eth0: can't fill rx buffer (force 0)! > > eth0: can't fill rx buffer (force 1)! > > This is the same problem, with a more direct error message. > > The driver cannot get memory from the kernel to fill the Rx descriptor > list. Presumably the kernel has temporarily run short of memory due to > bad VM/memory-management parameters. > > Tune the parameters in /proc/sys/vm/bdflush as described a few days ago > to avoid this performance problem. > > -- > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > From becker@scyld.com Sat Apr 27 01:34:01 2002 From: becker@scyld.com (Donald Becker) Date: Sat Apr 27 00:34:01 2002 Subject: [eepro100] KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463) In-Reply-To: Message-ID: On Sat, 27 Apr 2002, Wei Keong wrote: > I've another server down with the same rx buffer problem again. The funny > thing is both servers were down in the morning (5-6 am) where processing > is the lowest. Do you have any cron jobs scheduled for then? Check /etc/cron.daily and /etc/cron.weekly > Don't really understand why the kernel has not enough > memory for the network card... > Will tuning VM solve the problem? What are the possible side effects? I > still have a couple of server (with similar configs) and I'm not sure if I > should tune the VM, as a preventive messure. Please advise. The kernel's VM subsystem can run short of available memory for kernel needs even when the machine has lots of memory. Paradoxically, lots of memory seems to lead to worse short-term predictions of memory needs. Or perhaps it's a reduced ability to scan the page list for free pages that can be used for network buffers. [[ Mandatory gripe: We didn't have these problems with the VM system in the pre-2.2 kernels. ]] Anyway, tuning the VM parameters can definitely improve the situation. There should be a larger reserve of free pages when your machine has lots (64+MB) of installed memory. Having the kernel keeep 1-5MB ready for instantaneous use is very reasonable. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From chooweikeong@pacific.net.sg Sun Apr 28 23:12:01 2002 From: chooweikeong@pacific.net.sg (Wei Keong) Date: Sun Apr 28 22:12:01 2002 Subject: [eepro100] KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463) Message-ID: <001401c1ef23$16f17020$3b5f78cb@keong> >> I've another server down with the same rx buffer problem again. The funny >> thing is both servers were down in the morning (5-6 am) where processing >> is the lowest. >Do you have any cron jobs scheduled for then? >Check /etc/cron.daily and /etc/cron.weekly The servers will run a cron to compress and send a log file (~100 MB) to log cruncher. I doubt this will take up all the memory. However, there is a 'sleep 3600' in the cron job... will this cause some trouble? >> ./bdflush >> 10 0 0 0 100 3000 60 0 0 >Try >echo "100 500 200" > /proc/sys/vm/bdflush My current bdflush looks like this "40 0 0 0 500 3000 60 0 0". According to the doc (below), changing it to "100 500 200" would break the bdflush, wouldn't it? Donald, please advise. Thanks, Wei Keong >From linux/fs/buffer.c: -------------------------------------------------------------- union bdflush_param { struct { int nfract; /* Percentage of buffer cache dirty to activate bdflush */ int dummy1; /* old "ndirty" */ int dummy2; /* old "nrefill" */ int dummy3; /* unused */ int interval; /* jiffies delay between kupdate flushes */ int age_buffer; /* Time for normal buffer to age */ int nfract_sync;/* Percentage of buffer cache dirty to activate bdflush synchronously */ int dummy4; /* unused */ int dummy5; /* unused */ } b_un; unsigned int data[N_PARAM]; } bdf_prm = {{30, 64, 64, 256, 5*HZ, 30*HZ, 60, 0, 0}}; -------------------------------------------------------------- From mbarnes@compsci.wm.edu Tue Apr 30 13:09:01 2002 From: mbarnes@compsci.wm.edu (Michael Barnes) Date: Tue Apr 30 12:09:01 2002 Subject: [eepro100] is there a working driver for linux alpha Message-ID: <20020430120741.A31187@star.compsci.wm.edu> I have a 60 node alpha cluster (SMP with 2 processors in each node) with eepro100's in them that periodicly have NETDEV timeouts with moderate file transfers (~45Meg). I'm using kernel 2.4.9 with the supplied driver: eepro100.c:v1.09j-t eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin So far I have tried to update the TX|RX_RING_SIZE to 64, updated drivers from newer kernel sources, and the ones from scyld. The ones from scyld that I downloaded today load into the kernel fine, but I only get: eth0: Transmit timed out: status 0000 0010 at 0/15 commands 0001a000 00020000 00030000. [ snip ring dump ] eth0: Restarting the chip... Command 0070 was not accepted after 10001 polls! Command 0010 was not immediately accepted, 10001 ticks! Which repeats until I unload the driver. I have also tried the e100 driver from Intel, but that does not work either with Alphas. So does anyone have any suggestions for getting the eepro100 driver work on Alpha's or possibly another NIC that has functioning drivers? (I have also used DECchip based cards, but those too are problematic with negotiating 100FDX connections, even when forced). Thanks, Mike -- Michael Barnes UNIX Systems Administrator College of William and Mary Phone: (757) 207-3611 From ctierney@hpti.com Tue Apr 30 13:19:01 2002 From: ctierney@hpti.com (Craig Tierney) Date: Tue Apr 30 12:19:01 2002 Subject: [eepro100] is there a working driver for linux alpha In-Reply-To: <20020430120741.A31187@star.compsci.wm.edu>; from mbarnes@compsci.wm.edu on Tue, Apr 30, 2002 at 12:07:41PM -0400 References: <20020430120741.A31187@star.compsci.wm.edu> Message-ID: <20020430101559.C2674@hpti.com> I have 144 alpha nodes, 2 way SMP each. They all have the DE600 compaq card installed (eepro100 compatible). I am assuming you have the same one. We are using the same ethernet driver, but we are using the 2.4.14 kernel. We are not having any problems. Every card and every port on every switch is locked to 100FDX. We have had not problems with this setup. If you want to try the e100 driver, I suggest that you download the latest redhat kernel. It is included in their 3rd party drivers. I have never tried it myself, but I suspect that you might have a chance at getting that working. Craig > I have a 60 node alpha cluster (SMP with 2 processors in each node) > with eepro100's in them that periodicly have NETDEV timeouts with > moderate file transfers (~45Meg). I'm using kernel 2.4.9 with the > supplied driver: > > eepro100.c:v1.09j-t > eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin > > So far I have tried to update the TX|RX_RING_SIZE to 64, updated drivers > from newer kernel sources, and the ones from scyld. The ones from scyld > that I downloaded today load into the kernel fine, but I only get: > > eth0: Transmit timed out: status 0000 0010 at 0/15 commands 0001a000 00020000 00030000. > [ snip ring dump ] > eth0: Restarting the chip... > Command 0070 was not accepted after 10001 polls! > Command 0010 was not immediately accepted, 10001 ticks! > > Which repeats until I unload the driver. > > I have also tried the e100 driver from Intel, but that does not work > either with Alphas. > > So does anyone have any suggestions for getting the eepro100 driver > work on Alpha's or possibly another NIC that has functioning drivers? > (I have also used DECchip based cards, but those too are problematic > with negotiating 100FDX connections, even when forced). > > Thanks, > > Mike > > -- > Michael Barnes > UNIX Systems Administrator > College of William and Mary > Phone: (757) 207-3611 > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 -- Craig Tierney (ctierney@hpti.com) From mbarnes@compsci.wm.edu Tue Apr 30 15:07:01 2002 From: mbarnes@compsci.wm.edu (Michael Barnes) Date: Tue Apr 30 14:07:01 2002 Subject: [eepro100] is there a working driver for linux alpha In-Reply-To: <20020430101559.C2674@hpti.com>; from ctierney@hpti.com on Tue, Apr 30, 2002 at 10:16:00AM -0600 References: <20020430120741.A31187@star.compsci.wm.edu> <20020430101559.C2674@hpti.com> Message-ID: <20020430140607.B31187@star.compsci.wm.edu> On Tue, Apr 30, 2002 at 10:16:00AM -0600, Craig Tierney wrote: > I have 144 alpha nodes, 2 way SMP each. They all have the DE600 > compaq card installed (eepro100 compatible). I am assuming you > have the same one. No, these are standard Intel PCI cards. > We are using the same ethernet driver, but we are using the 2.4.14 > kernel. We are not having any problems. I don't know if the kernel has anything to do with these problems or not. For right now, I'm stuck with the 2.4.9 kernel because the newer ones have issues with the SCSI controler (Symbios Logic 53c1010). The kernel panics because it cannot find a harddisk. > If you want to try the e100 driver, I suggest that you download > the latest redhat kernel. It is included in their 3rd party drivers. > I have never tried it myself, but I suspect that you might have > a chance at getting that working. I've done this as well, but the driver loads after insmod and negotiates the connection, but no data will go over the wire. This is the same behavior I found with the e1000 (gigabit) driver, for a e1000 card. (I have not found a gigabit card for the alpha either). Mike > > I have a 60 node alpha cluster (SMP with 2 processors in each node) > > with eepro100's in them that periodicly have NETDEV timeouts with > > moderate file transfers (~45Meg). I'm using kernel 2.4.9 with the > > supplied driver: > > > > eepro100.c:v1.09j-t > > eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin > > > > So far I have tried to update the TX|RX_RING_SIZE to 64, updated drivers > > from newer kernel sources, and the ones from scyld. The ones from scyld > > that I downloaded today load into the kernel fine, but I only get: > > > > eth0: Transmit timed out: status 0000 0010 at 0/15 commands 0001a000 00020000 00030000. > > [ snip ring dump ] > > eth0: Restarting the chip... > > Command 0070 was not accepted after 10001 polls! > > Command 0010 was not immediately accepted, 10001 ticks! > > > > Which repeats until I unload the driver. > > > > I have also tried the e100 driver from Intel, but that does not work > > either with Alphas. > > > > So does anyone have any suggestions for getting the eepro100 driver > > work on Alpha's or possibly another NIC that has functioning drivers? > > (I have also used DECchip based cards, but those too are problematic > > with negotiating 100FDX connections, even when forced). From brian@mastermnd.myip.org Tue Apr 30 18:42:01 2002 From: brian@mastermnd.myip.org (Brian Johnson) Date: Tue Apr 30 17:42:01 2002 Subject: [eepro100] wait_for_cmd_done timeout! Message-ID: <20020430214118.GA2035@mastermnd.myip.org> --MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm getting this error. I read the archives, and noticed a few other people seem to be having this = problem. I'm on a 10 baseT hub and using DHCP. Sometimes my system continues running (without networking), sometimes it lo= cks-up. Today I lost my network connection, but then I got the attached messages, a= nd the network connection resumed. I didn't notice the message in the arch= ives previously, and don't know if it provides any more info. If I can provide any more helpful information please let me know.. --=20 Brian Johnson --MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=syslog Apr 30 13:30:32 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:31:07 mcp last message repeated 6 times Apr 30 13:31:53 mcp last message repeated 7 times Apr 30 13:32:38 mcp last message repeated 3 times Apr 30 13:33:53 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:33:55 mcp last message repeated 2 times Apr 30 13:34:01 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:34:03 mcp last message repeated 2 times Apr 30 13:34:16 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:34:18 mcp last message repeated 2 times Apr 30 13:34:34 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:34:48 mcp last message repeated 5 times Apr 30 13:35:06 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:35:32 mcp last message repeated 3 times Apr 30 13:35:33 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:36:04 mcp last message repeated 16 times Apr 30 13:36:06 mcp last message repeated 2 times Apr 30 13:36:07 mcp kernel: eepro100: wait_for_cmd_done timeout! Apr 30 13:36:18 mcp last message repeated 2 times Apr 30 13:36:22 mcp kernel: NETDEV WATCHDOG: eth0: transmit timed out Apr 30 13:36:22 mcp kernel: eth0: Transmit timed out: status 0050 0c80 at 4688/4748 command 200c0000. Apr 30 13:36:22 mcp kernel: eth0: Tx ring dump, Tx queue 4748 / 4688: Apr 30 13:36:22 mcp kernel: eth0: 0 200c0000. Apr 30 13:36:22 mcp kernel: eth0: 1 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 2 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 3 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 4 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 5 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 6 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 7 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 8 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 9 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 10 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 11 400c0000. Apr 30 13:36:22 mcp kernel: eth0: =12 000ca000. Apr 30 13:36:22 mcp kernel: eth0: 13 000ca000. Apr 30 13:36:22 mcp kernel: eth0: 14 000ca000. Apr 30 13:36:22 mcp kernel: eth0: 15 000ca000. Apr 30 13:36:22 mcp kernel: eth0: * 16 200c0000. Apr 30 13:36:22 mcp kernel: eth0: 17 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 18 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 19 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 20 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 21 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 22 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 23 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 24 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 25 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 26 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 27 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 28 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 29 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 30 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 31 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 32 200c0000. Apr 30 13:36:22 mcp kernel: eth0: 33 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 34 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 35 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 36 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 37 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 38 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 39 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 40 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 41 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 42 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 43 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 44 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 45 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 46 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 47 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 48 200c0000. Apr 30 13:36:22 mcp kernel: eth0: 49 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 50 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 51 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 52 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 53 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 54 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 55 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 56 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 57 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 58 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 59 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 60 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 61 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 62 000c0000. Apr 30 13:36:22 mcp kernel: eth0: 63 000c0000. Apr 30 13:36:22 mcp kernel: eth0: Printing Rx ring (next to receive into 6478, dirty index 6478). Apr 30 13:36:22 mcp kernel: eth0: 0 00000001. Apr 30 13:36:22 mcp kernel: eth0: 1 00000001. Apr 30 13:36:22 mcp kernel: eth0: 2 00000001. Apr 30 13:36:22 mcp kernel: eth0: 3 00000001. Apr 30 13:36:22 mcp kernel: eth0: 4 00000001. Apr 30 13:36:22 mcp kernel: eth0: 5 00000001. Apr 30 13:36:22 mcp kernel: eth0: 6 00000001. Apr 30 13:36:22 mcp kernel: eth0: 7 00000001. Apr 30 13:36:22 mcp kernel: eth0: 8 00000001. Apr 30 13:36:22 mcp kernel: eth0: 9 00000001. Apr 30 13:36:22 mcp kernel: eth0: 10 00000001. Apr 30 13:36:22 mcp kernel: eth0: 11 00000001. Apr 30 13:36:22 mcp kernel: eth0: 12 00000001. Apr 30 13:36:22 mcp kernel: eth0: l 13 c0000001. Apr 30 13:36:22 mcp kernel: eth0: *=14 00000001. Apr 30 13:36:22 mcp kernel: eth0: 15 00000001. Apr 30 13:36:22 mcp kernel: eth0: 16 00000001. Apr 30 13:36:22 mcp kernel: eth0: 17 00000001. Apr 30 13:36:22 mcp kernel: eth0: 18 00000001. Apr 30 13:36:22 mcp kernel: eth0: 19 00000001. Apr 30 13:36:22 mcp kernel: eth0: 20 00000001. Apr 30 13:36:22 mcp kernel: eth0: 21 00000001. Apr 30 13:36:22 mcp kernel: eth0: 22 00000001. Apr 30 13:36:22 mcp kernel: eth0: 23 00000001. Apr 30 13:36:22 mcp kernel: eth0: 24 00000001. Apr 30 13:36:22 mcp kernel: eth0: 25 00000001. Apr 30 13:36:22 mcp kernel: eth0: 26 00000001. Apr 30 13:36:22 mcp kernel: eth0: 27 00000001. Apr 30 13:36:22 mcp kernel: eth0: 28 00000001. Apr 30 13:36:22 mcp kernel: eth0: 29 00000001. Apr 30 13:36:22 mcp kernel: eth0: 30 00000001. Apr 30 13:36:22 mcp kernel: eth0: 31 00000001. Apr 30 13:36:22 mcp kernel: eth0: 32 00000001. Apr 30 13:36:22 mcp kernel: eth0: 33 00000001. Apr 30 13:36:22 mcp kernel: eth0: 34 00000001. Apr 30 13:36:22 mcp kernel: eth0: 35 00000001. Apr 30 13:36:22 mcp kernel: eth0: 36 00000001. Apr 30 13:36:22 mcp kernel: eth0: 37 00000001. Apr 30 13:36:22 mcp kernel: eth0: 38 00000001. Apr 30 13:36:22 mcp kernel: eth0: 39 00000001. Apr 30 13:36:22 mcp kernel: eth0: 40 00000001. Apr 30 13:36:22 mcp kernel: eth0: 41 00000001. Apr 30 13:36:22 mcp kernel: eth0: 42 00000001. Apr 30 13:36:22 mcp kernel: eth0: 43 00000001. Apr 30 13:36:22 mcp kernel: eth0: 44 00000001. Apr 30 13:36:22 mcp kernel: eth0: 45 00000001. Apr 30 13:36:22 mcp kernel: eth0: 46 00000001. Apr 30 13:36:22 mcp kernel: eth0: 47 00000001. Apr 30 13:36:22 mcp kernel: eth0: 48 00000001. Apr 30 13:36:22 mcp kernel: eth0: 49 00000001. Apr 30 13:36:22 mcp kernel: eth0: 50 00000001. Apr 30 13:36:22 mcp kernel: eth0: 51 00000001. Apr 30 13:36:22 mcp kernel: eth0: 52 00000001. Apr 30 13:36:22 mcp kernel: eth0: 53 00000001. Apr 30 13:36:22 mcp kernel: eth0: 54 00000001. Apr 30 13:36:22 mcp kernel: eth0: 55 00000001. Apr 30 13:36:22 mcp kernel: eth0: 56 00000001. Apr 30 13:36:22 mcp kernel: eth0: 57 00000001. Apr 30 13:36:22 mcp kernel: eth0: 58 00000001. Apr 30 13:36:22 mcp kernel: eth0: 59 00000001. Apr 30 13:36:22 mcp kernel: eth0: 60 00000001. Apr 30 13:36:22 mcp kernel: eth0: 61 00000001. Apr 30 13:36:22 mcp kernel: eth0: 62 00000001. Apr 30 13:36:22 mcp kernel: eth0: 63 00000001. --MfFXiAuoTsnnDAfZ-- From becker@scyld.com Tue Apr 30 19:16:02 2002 From: becker@scyld.com (Donald Becker) Date: Tue Apr 30 18:16:02 2002 Subject: [eepro100] wait_for_cmd_done timeout! In-Reply-To: <20020430214118.GA2035@mastermnd.myip.org> Message-ID: On Tue, 30 Apr 2002, Brian Johnson wrote: > Subject: [eepro100] wait_for_cmd_done timeout! > > Hi, I'm getting this error. > I read the archives, and noticed a few other people seem to be having > this problem. There are several problems that can cause this message. What driver are you using? Run 'eepro100-diag -a' when the interface stops to see the status. > I'm on a 10 baseT hub and using DHCP. Have you run 'eepro100-diag -ee' to verify that sleep mode is not enabled? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue Apr 30 19:16:13 2002 From: becker@scyld.com (Donald Becker) Date: Tue Apr 30 18:16:13 2002 Subject: [eepro100] is there a working driver for linux alpha In-Reply-To: <20020430140607.B31187@star.compsci.wm.edu> Message-ID: On Tue, 30 Apr 2002, Michael Barnes wrote: > > We are using the same ethernet driver, but we are using the 2.4.14 > > kernel. We are not having any problems. > > I don't know if the kernel has anything to do with these problems or > not. For right now, I'm stuck with the 2.4.9 kernel because the newer > ones have issues with the SCSI controler (Symbios Logic 53c1010). The > kernel panics because it cannot find a harddisk. I suspect the kernel. Your earlier message indicates that the driver failed to transmit _any_ packets. The problem could be with the PCI bus-master parameters. Check the driver detection message to verify that the self-test passed. The self-test won't verify data transfer, but it will check that the bus-master arbitration is at least minimally working. > > If you want to try the e100 driver, I suggest that you download .. > behavior I found with the e1000 (gigabit) driver, for a e1000 card. (I > have not found a gigabit card for the alpha either). That's one advantage of the eepro100.c and intel-gige.c drivers -- they were written to work on 64 bit and big-endian machine. Intel doesn't have the same motivation for multi-architecture compatibility. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993