From RWMarch@sympatico.ca Thu Jan 2 08:52:01 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Thu Jan 2 08:52:01 2003 Subject: [tulip] Building on RH7.3 from netdrivers-3.3 Message-ID: <200301012318.05709.RWMarch@sympatico.ca> I purchased a Netgear FA511 CardBus adapter for my Thinkpad 600E running RH7.3 with the 2.4.19 kernel. The supplied driver failed to compile on this system. So I grabbed netdrivers-3.3.tgz and unpacked it. In the Makefile I set: PCMCIA?=/usr/src/linux/include/pcmcia But, $ make also fails with: Makefile:46: No kernel version has been specified. Assuming 2.4.18-19.7.x. Set the KERNVER variable to specify a different kernel. cc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I/lib/modules/2.4.18-19.7.x/build/include/ -pipe -fno-strength-reduce -DMODVERSIONS -c -o pci-skeleton.o pci-skeleton.c In file included from /lib/modules/2.4.18-19.7.x/build/include/linux/spinlock.h:56, from /lib/modules/2.4.18-19.7.x/build/include/linux/module.h:11, from pci-skeleton.c:106: /lib/modules/2.4.18-19.7.x/build/include/asm/spinlock.h:9: nondigits in number and not hexadecimal /lib/modules/2.4.18-19.7.x/build/include/asm/spinlock.h:9: nondigits in number and not hexadecimal /lib/modules/2.4.18-19.7.x/build/include/asm/spinlock.h:9: parse error before `1b7d4074' /lib/modules/2.4.18-19.7.x/build/include/asm/spinlock.h:10: `printk_R_ver_str' declared as function returning a function /lib/modules/2.4.18-19.7.x/build/include/asm/spinlock.h:10: warning: function declaration isn't a prototype In file included from /lib/modules/2.4.18-19.7.x/build/include/linux/prefetch.h:13, from /lib/modules/2.4.18-19.7.x/build/include/linux/list.h:6, from /lib/modules/2.4.18-19.7.x/build/include/linux/module.h:12, [snipped] The targetted kernel is correct. Could someone point me in the right direction to deal with this? Alternatively, Mr. Becker's online docs mention that pre-compiled drivers are available but, I could not find where they might be. Can someone point them out? In the docs, the driver update page appears to recommend the SRPM route as the prefer technique but ftp://ftp.scyld.com/pub/network/netdrivers-3.1-1.src.rpm does not appear to exist. -Robert -- Robert W March St. Andrew's House L'Orignal Ontario Canada From becker@scyld.com Thu Jan 2 10:22:01 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 2 10:22:01 2003 Subject: [tulip] Building on RH7.3 from netdrivers-3.3 In-Reply-To: <200301012318.05709.RWMarch@sympatico.ca> Message-ID: On Wed, 1 Jan 2003, Robert W March wrote: > I purchased a Netgear FA511 CardBus adapter for my Thinkpad 600E > running RH7.3 with the 2.4.19 kernel. The supplied driver failed to > compile on this system. > > So I grabbed netdrivers-3.3.tgz and unpacked it. In the Makefile I set: > PCMCIA?=/usr/src/linux/include/pcmcia You should not need to change this with a 2.4 kernel that is using the in-kernel support. This is needed if you are using David Hinds original PCMCIA package (a few 2.4 configuration, and all 2.2 and earlier systems). > /lib/modules/2.4.18-19.7.x/build/include/asm/spinlock.h:9: nondigits in number > and not hexadecimal Red Hat modifies the kernel source, and the modifications are different for the different releases. What does your copy of spinlock.h have on this line? > Alternatively, Mr. Becker's online docs mention that pre-compiled > drivers are available but, I could not find where they might be. Can > someone point them out? They way "might be available". Red Hat has many different kernels for the same distribution number, so this has become too difficult. We now supply precompiled drivers for the Scyld distribution only. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From RWMarch@sympatico.ca Thu Jan 2 10:26:01 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Thu Jan 2 10:26:01 2003 Subject: [tulip] Building on RH7.3 from netdrivers-3.3 Message-ID: <200301012318.05709.RWMarch@sympatico.ca> In my original post, I said: I purchased a Netgear FA511 CardBus adapter for my Thinkpad 600E running RH7.3 with the 2.4.19 kernel. The supplied driver failed to compile on this system. Correction: _2.4.18 kernel_ -Robert -- Robert W March St. Andrew's House L'Orignal Ontario Canada From RWMarch@sympatico.ca Thu Jan 2 15:18:00 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Thu Jan 2 15:18:00 2003 Subject: [tulip] Building on RH7.3 from netdrivers-3.3 In-Reply-To: References: Message-ID: <200301021308.40659.RWMarch@sympatico.ca> On January 2, 2003 10:22, you wrote: > You should not need to change this with a 2.4 kernel that is using the > in-kernel support. This is needed if you are using David Hinds original > PCMCIA package (a few 2.4 configuration, and all 2.2 and earlier systems). OK. Understood. > > /lib/modules/2.4.18-19.7.x/build/include/asm/spinlock.h:9: nondigits in > > number and not hexadecimal > > Red Hat modifies the kernel source, and the modifications are different > for the different releases. What does your copy of spinlock.h have on > this line? I have the current stock RH7.3 version of spinlock.h . The block in the neighbourhood of line 56 says: #ifdef CONFIG_SMP #include #elif !defined(spin_lock_init) /* !SMP and spin_lock_init not previously defined (e.g. by including asm/spinlock.h */ And my .config happens to have: CONFIG_SMP=y and the code surrounding line 56 in asm/spinlock.h says: #define spin_lock_string \ "\n1:\t" \ "lock ; decb %0\n\t" \ "js 2f\n" \ LOCK_SECTION_START("") \ "2:\t" \ "cmpb $0,%0\n\t" \ "rep;nop\n\t" \ "jle 2b\n\t" \ "jmp 1b\n" \ LOCK_SECTION_END Thanking you for your help, Robert -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From RWMarch@sympatico.ca Thu Jan 2 15:18:39 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Thu Jan 2 15:18:39 2003 Subject: [tulip] Building on RH7.3 from netdrivers-3.3 In-Reply-To: References: Message-ID: <200301021321.45263.RWMarch@sympatico.ca> On January 2, 2003 10:22, you wrote: > They way "might be available". > Red Hat has many different kernels for the same distribution number, so > this has become too difficult. We now supply precompiled drivers for > the Scyld distribution o Yes, you are quite right. And when I try to make modules with the tulip driver configured as a module, I get failure messages similar to what I have reported earlier about non-digits in number, etc. -Robert -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From ch0wn@myself.com Fri Jan 3 22:15:02 2003 From: ch0wn@myself.com (Adriano Carvalho) Date: Fri Jan 3 22:15:02 2003 Subject: [tulip] Conexant Lanfinity COMBO doesnt send anything Message-ID: <20030104031351.83668.qmail@mail.com> Hi people I have a problem with my tulip driver. I use slackware linux 8.1, with kernel 2.4.20 , and I have a conexant Lanfinity COMBO, at Compaq 1400 laptop. The driver tulip of kernel 2.4.20 works here, it loaded, but when I try ping other machine, it just send 46 bytes and stop. The other machine send a ping, continue trying , but it doesnt stop. (and the ping is lost, 100%) Here are 2 machines slackware 8.1, with kernel 2.4.20. I think that the problem is in this machine, with tulip driver. These are the errors in ifconfig eth0 : eth0 Link encap:Ethernet HWaddr 00:4C:69:6E:75:79 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:27 dropped:0 overruns:0 carrier:20 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:42 (42.0 b) Interrupt:11 Base address:0x1400 aNYBODY KNOWS hOW CAN i FIX IT ? tHANKS FOR ALL aDRIANO cARVALHO. ps : sORRY FOR MY ENGLISH. -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife From becker@scyld.com Sat Jan 4 01:20:00 2003 From: becker@scyld.com (Donald Becker) Date: Sat Jan 4 01:20:00 2003 Subject: [tulip] Conexant Lanfinity COMBO doesnt send anything In-Reply-To: <20030104031351.83668.qmail@mail.com> Message-ID: On Fri, 3 Jan 2003, Adriano Carvalho wrote: > I have a problem with my tulip driver. > I use slackware linux 8.1, with kernel 2.4.20 , and I have a conexant > Lanfinity COMBO, at Compaq 1400 laptop. What is the driver version? What is the detection message? > The driver tulip of kernel 2.4.20 works here, it loaded, but when I > try ping other machine, it just send 46 bytes and stop. ... > eth0 Link encap:Ethernet HWaddr 00:4C:69:6E:75:79 This is clearly not a working driver... that address means that the card was not correctly initialized. The unmodified driver from Scyld should work correctly. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From ch0wn@myself.com Sat Jan 4 02:33:01 2003 From: ch0wn@myself.com (Adriano Carvalho) Date: Sat Jan 4 02:33:01 2003 Subject: [tulip] Conexant LANfinity COMBO doenst send anythinf Message-ID: <20030104073234.28109.qmail@mail.com> >What is the driver version? >What is the detection message? The driver version is 0.9.15-pre12, but I've downloaded netdrivers.tgz and It doesnt work too. I've tried with netdrivers-3.3.tgz, and it sends 42 bytes sometimes, but other computes doesnt receive anything. After a time, it stopped. dmesg is : pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.com/linux/drivers.html tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: Conexant LANfinity rev 8 at 0xd405e000, 00:90:96:02:E4:57, IRQ 11. eth0: MII transceiver #1 config 1000 status 782d advertising 0020. eth0: MII transceiver #0 config 1000 status 782d advertising 0020. That's all. My other computer doesnt receive any byte, and my conexant lanfinity sends sometimes 60 bytes, that it's lost. Thanks Adriano -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife From acme341@canal21.com Sat Jan 4 10:11:02 2003 From: acme341@canal21.com (acme341@canal21.com) Date: Sat Jan 4 10:11:02 2003 Subject: [tulip] yxttffipcg Attn: PROTECT YOUR COMPUTER AND YOUR VALUABLE INFORMATION! Message-ID: <001400c4ce13$ebd17600$7836844d@ykkxcavu> hgellxm cjss ocyi *NEW-Special Package Deal!* Norton SystemWorks 2003 Software Suite -Professional Edition- ATTN: This is a MUST for ALL Computer Users!!! Includes SIX - Feature-Packed Utilities...ALL For ONE Special LOW Price! -Norton AntiVirus 2003 -Norton Ghost 2003 -GoBack 3 Personal Edition -Norton Utilities 2003 -Norton CleanSweep 2003 -Norton WinFax Basic Edition This Software Will: - Protect your computer from unwanted and hazardous viruses - Help secure your private & valuable information - Allow you to transfer files and send e-mails safely - Backup your ALL your data quick and easily - Improve your PC's performance w/superior integral diagnostics! Six Feature-Packed Utilities...For One Great Price! A $300-Plus Combined Retail Value! YOURS for Only $39.99! (Includes **FREE** Shipping TOO!) Don't fall prey to destructive viruses or hackers! Protect your computer and your valuable information! CLICK HERE to Order Yours NOW! http://antiviruschannel.com/nsw15.htm ------------ Opt-Out Instructions: We are strongly against sending unsolicited emails to those who do not wish to receive our special mailings. You have opted in to one or more of our affiliate sites requesting to be notified of any special offers we may run from time to time. We also 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 visit the link below be removed from the list. Please accept our apologies if you have been sent this email in error. We honor all removal requests. Submit your remove request at: http://antiviruschannel.com/goodbye.html cjss 9971komD6-890nShU2826HcRV5-430VRMH2270uCYS0-749tgYd5846PHws6-544mNJX1931uVzO3-149l76 From becker@scyld.com Sat Jan 4 12:36:02 2003 From: becker@scyld.com (Donald Becker) Date: Sat Jan 4 12:36:02 2003 Subject: [tulip] Conexant LANfinity COMBO doenst send anythinf In-Reply-To: <20030104073234.28109.qmail@mail.com> Message-ID: On Sat, 4 Jan 2003, Adriano Carvalho wrote: > >What is the driver version? > >What is the detection message? > > The driver version is 0.9.15-pre12, but I've downloaded netdrivers.tgz and It doesnt work too. > I've tried with netdrivers-3.3.tgz, and it sends 42 bytes sometimes, but other computes doesnt receive anything. After a time, it stopped. What does 'tulip-diag' report after it stops? What are the error messages from the driver? > dmesg is : > pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.com/linux/drivers.html > tulip.c:v0.95f 11/17/2002 Written by Donald Becker > http://www.scyld.com/network/tulip.html > eth0: Conexant LANfinity rev 8 at 0xd405e000, 00:90:96:02:E4:57, IRQ 11. > eth0: MII transceiver #1 config 1000 status 782d advertising 0020. > eth0: MII transceiver #0 config 1000 status 782d advertising 0020. This looks normal. Two notes The station address has been read correctly, unlike the 0.9.* driver. You seem to have passed a module option that sets the transceiver to advertise only 10baseT. Was that intentional? Does the link partner expect this? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From ch0wn@myself.com Sat Jan 4 15:22:01 2003 From: ch0wn@myself.com (Adriano Carvalho) Date: Sat Jan 4 15:22:01 2003 Subject: [tulip] Re: Conexant LANfinity COMBO doenst send anything Message-ID: <20030104202041.69612.qmail@mail.com> Donald Becker wrote : >What does 'tulip-diag' report after it stops? >What are the error messages from the driver? Tulip-dialog : tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1800. Port selection is MII, half-duplex. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. With option -e : tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1800. Port selection is MII, half-duplex. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. EEPROM 256 words, 8 address bits. Conexant EEPROM format is undocumented. Now (18:13 in Brazil) my ethernet card isnt send anything, its stopped. eth0 Link encap:Ethernet HWaddr 00:90:96:02:E4:57 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:12 dropped:0 overruns:0 carrier:26 >The station address has been read correctly, unlike >the 0.9.* driver. > You seem to have passed a module option that sets >the transceiver to > advertise only 10baseT. Was that intentional? No, its not. Sorry, But my webmail is a shit. Theres a bug here, so , everything that I put here is "mixtured". I'll send later other mail by hotmail (eca).=) >Does the link > collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Base address:0xe000 So, I type ifconfig eth0 and this is : -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife From ch0wn_@hotmail.com Sat Jan 4 15:45:01 2003 From: ch0wn_@hotmail.com (Adriano Carvalho) Date: Sat Jan 4 15:45:01 2003 Subject: [tulip] Conexant LANfinify doesnt send anything Message-ID: Now I'll show every informations about my ethernet card : today its not sending anything, its just stopped. I made : insmod ./pci-scan.o insmod ./tulip.o ifconfig eth0 192.168.1.2 netmask 255.255.255.0 So, when I try ping 192.168.1.1 (other machine), its not send . Tulip-dialog : Index #1: Found a Conexant LANfinity adapter at 0x1800. Port selection is MII, full-duplex. Transmit stopped, Receive stopped. The Rx process state is 'Waiting for packets'. The Tx process state is 'Stopped'. The transmit threshold is 128. Interrupt sources are pending! CSR5 is f4068002. Tx complete indication. Tulip-dialog -e : Index #1: Found a Conexant LANfinity adapter at 0x1800. Port selection is MII, full-duplex. Transmit stopped, Receive stopped. The Rx process state is 'Waiting for packets'. The Tx process state is 'Stopped'. The transmit threshold is 128. Interrupt sources are pending! CSR5 is f4068002. Tx complete indication. EEPROM 256 words, 8 address bits. Conexant EEPROM format is undocumented. dmesg today : m/linux/drivers.html tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: Conexant LANfinity rev 8 at 0xd405e000, 00:90:96:02:E4:57, IRQ 11. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. eth0: MII transceiver #0 config 1000 status 782d advertising 01e1. Trying to free nonexistent resource tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: Conexant LANfinity rev 8 at 0xd405e000, 00:90:96:02:E4:57, IRQ 11. eth0: MII transceiver #1 config 1000 status 7829 advertising 01e1. eth0: MII transceiver #0 config 1000 status 782d advertising 01e1. Trying to free nonexistent resource That's all . I have a compaq presario 1400 with slackware 8.1 kernel 2.4.20. This driver that I'm using is netdrivers-3.3.tgz. Thanks for all. Adriano Carvalho. _________________________________________________________________ MSN Hotmail, o maior webmail do Brasil. http://www.hotmail.com From becker@scyld.com Sat Jan 4 16:00:01 2003 From: becker@scyld.com (Donald Becker) Date: Sat Jan 4 16:00:01 2003 Subject: [tulip] Conexant LANfinify doesnt send anything In-Reply-To: Message-ID: On Sat, 4 Jan 2003, Adriano Carvalho wrote: > Now I'll show every informations about my ethernet card : today its not > sending anything, its just stopped. I made : > insmod ./pci-scan.o > insmod ./tulip.o > ifconfig eth0 192.168.1.2 netmask 255.255.255.0 > > So, when I try ping 192.168.1.1 (other machine), its not send . > Tulip-dialog : > > Index #1: Found a Conexant LANfinity adapter at 0x1800. > Port selection is MII, full-duplex. > Transmit stopped, Receive stopped. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Stopped'. > The transmit threshold is 128. > Interrupt sources are pending! CSR5 is f4068002. > Tx complete indication. You have an interrupt problem. Interrupts are not causing the interrupt handler to be run. This might be an issue for the kernel mailing list. > tulip.c:v0.95f 11/17/2002 Written by Donald Becker > http://www.scyld.com/network/tulip.html > eth0: Conexant LANfinity rev 8 at 0xd405e000, 00:90:96:02:E4:57, IRQ 11. > eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. The advertised capability is now correct. What does /proc/interrupts report about IRQ11? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From ch0wn_@hotmail.com Sat Jan 4 16:51:00 2003 From: ch0wn_@hotmail.com (Adriano Carvalho) Date: Sat Jan 4 16:51:00 2003 Subject: [tulip] Re: Conexant LANfinity doesnt send anything Message-ID: Donald Becker wrote : >You have an interrupt problem. >Interrupts are not causing the interrupt handler to be run. >This might be an issue for the kernel mailing list. I dont know how to solve it.If anybody can help me, I thanks.. >The advertised capability is now correct. >What does /proc/interrupts report about IRQ11? Is it correct ? The /proc/interrupts about IRQ 11 is : 11: 300432 XT-PIC Texas Instruments PCI1410 PC card Cardbus Controller, hcf Is there solution ? Thanks Adriano. _________________________________________________________________ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br From becker@scyld.com Sun Jan 5 21:40:01 2003 From: becker@scyld.com (Donald Becker) Date: Sun Jan 5 21:40:01 2003 Subject: [tulip] Re: Conexant LANfinity doesnt send anything In-Reply-To: Message-ID: On Sat, 4 Jan 2003, Adriano Carvalho wrote: > Donald Becker wrote : > >You have an interrupt problem. > >Interrupts are not causing the interrupt handler to be run. > >This might be an issue for the kernel mailing list. > I dont know how to solve it.If anybody can help me, I thanks.. > > >The advertised capability is now correct. > >What does /proc/interrupts report about IRQ11? > > Is it correct ? > The /proc/interrupts about IRQ 11 is : > > 11: 300432 XT-PIC Texas Instruments PCI1410 PC card Cardbus > Controller, hcf Try shut down the PCMCIA subsystem service pcmcia stop note the interrupt count for IRQ11 ("300432" in the line above) start the network interface note the interrupt count for IRQ11 You should get approximately one interrupt for every packet sent or received. If you don't, you have a problem with the interrupt routing. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From RWMarch@sympatico.ca Mon Jan 6 09:31:00 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Mon Jan 6 09:31:00 2003 Subject: [tulip] FA511 not passing data Message-ID: <200301060904.51559.RWMarch@sympatico.ca> Hello, I installed a NetGear FA511 PCBus card on a Thinkpad 600E running RH7.3 and the card shows up as: 05:00.0 Ethernet controller: Linksys Fast Ethernet 10/100 (rev 11) Subsystem: Netgear: Unknown device 511a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://www.scyld.com/linux/drivers.html tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html The PCI BIOS has not enabled the device at 5/0! Updating PCI command 0003->0007. eth0: ADMtek Centaur-C rev 17 at 0xd29ee000, EEPROM not present, 00:4C:69:6E:75:79, IRQ 11. eth0: MII transceiver #1 config 3100 status 7869 advertising 05e1. PCI: Setting latency timer of device 05:00.0 to 64 tulip-diag -eee reports: tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-C adapter at 0x4800. Comet duplex is reported in the MII status registers. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Comet MAC address registers 6e694c00 ffff7975 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. WARNING: The EEPROM is missing or erased! Ethernet MAC Station Address ff:ff:ff:ff:ff:ff. Default connection type 'Default'. PCI IDs Vendor ffff Device ffff Subsystem ffff ffff PCI min_grant 255 max_latency 255. CSR18 power-up setting 0xffff****. EEPROM contents (256 words): 0x00: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x08: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x10: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x18: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x20: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x28: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x30: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x38: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x40: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x48: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x50: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x58: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x60: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x68: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x70: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x78: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x80: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x88: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x90: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x98: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xa0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xa8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xb0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xb8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xc0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xc8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xd0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xd8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xf8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ ID block CRC 0xfa (vs. 0xff). Full contents CRC 0x6a15 (read as 0xffff). I see similar issues posted on this list but I have not seen a solution. Any suggestions appreciated. -Robert -- Robert W March St. Andrew's House L'Orignal Ontario Canada From becker@scyld.com Mon Jan 6 15:49:02 2003 From: becker@scyld.com (Donald Becker) Date: Mon Jan 6 15:49:02 2003 Subject: [tulip] FA511 not passing data In-Reply-To: <200301060904.51559.RWMarch@sympatico.ca> Message-ID: On Mon, 6 Jan 2003, Robert W March wrote: > I installed a NetGear FA511 PCBus card on a Thinkpad 600E running RH7.3 and > the card shows up as: > 05:00.0 Ethernet controller: Linksys Fast Ethernet 10/100 (rev 11) > Subsystem: Netgear: Unknown device 511a That's strange -- it's a NetGear card, right? It might be just the name list, which is frequently wrong. What are the numeric values for IDs? (Use the '-n' option.) > Region 0: I/O ports at 4800 [size=256] > Region 1: Memory at 12c00000 (32-bit, non-prefetchable) [size=1K] .. > I built and installed netdrivers-3.3. All installed OK except: > depmod: *** Unresolved symbols in > /lib/modules/2.4.18-19.7.x/kernel/drivers/pcmcia/cb_shim.o > > Maybe cb_shim.o is not needed, or is it? It is only needed if you are using the original PCMCIA code. Unfortunately, there is no good way to detect that at compile time. So the Makefile unconditionally builds the module. The card is not working. ping says: > PING cougar.localdomain (192.168.0.252) from 192.168.0.10 : 56(84) bytes of > data. > 64 bytes from cougar.localdomain (192.168.0.252): icmp_seq=1 ttl=64 time=0.570 > ms ... > 14 packets transmitted, 3 received, 78% loss, time 13064ms > rtt min/avg/max/mdev = 0.303/0.400/0.570/0.121 ms It's work a little bit... that narrows down the problem. > dmesg says: > pci-scan.c:v1.11 8/31/2002 Donald Becker > http://www.scyld.com/linux/drivers.html > tulip.c:v0.95f 11/17/2002 Written by Donald Becker > http://www.scyld.com/network/tulip.html > The PCI BIOS has not enabled the device at 5/0! Updating PCI command > 0003->0007. That's curious! I'm guessing that there is an error message from the CardBus code, likely earlier in the boot sequence. > eth0: ADMtek Centaur-C rev 17 at 0xd29ee000, EEPROM not present, > 00:4C:69:6E:75:79, IRQ 11. This is a Bad Thing. The driver had to make up a station address. If the EEPROM is really erased or missing, card-specific NIC parameters have not been loaded. > eth0: MII transceiver #1 config 3100 status 7869 advertising 05e1. What does 'mii-diag' report? > tulip-diag -eee reports: > tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a ADMtek AL985 Centaur-C adapter at 0x4800. > Comet duplex is reported in the MII status registers. > Transmit started, Receive started. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 128. Normal operation so far. > Comet MAC address registers 6e694c00 ffff7975 > Comet multicast filter 0000000040000000. > EEPROM 256 words, 8 address bits. > WARNING: The EEPROM is missing or erased! > Ethernet MAC Station Address ff:ff:ff:ff:ff:ff. > Default connection type 'Default'. > PCI IDs Vendor ffff Device ffff Subsystem ffff ffff Hmmm, something is wrong. The chip did manage to load the subsystem ID, so part of the EEPROM is programmed. > I see similar issues posted on this list but I have not seen a > solution. What similar issues? I haven't noticed another error report that matches this one. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From RWMarch@sympatico.ca Tue Jan 7 13:46:03 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Tue Jan 7 13:46:03 2003 Subject: [tulip] FA511 not passing data In-Reply-To: References: Message-ID: <200301062306.45436.RWMarch@sympatico.ca> On January 6, 2003 10:00, you wrote: > On Mon, 6 Jan 2003, Robert W March wrote: > > I installed a NetGear FA511 PCBus card on a Thinkpad 600E running RH7.3 > > and the card shows up as: > > 05:00.0 Ethernet controller: Linksys Fast Ethernet 10/100 (rev 11) > > Subsystem: Netgear: Unknown device 511a > > That's strange -- it's a NetGear card, right? It might be just the name > list, which is frequently wrong. What are the numeric values for IDs? > (Use the '-n' option.) Yes, the label / box / docs say NetGear. "Made in Taiwan", purchased at a major retailer in Canada. [root@beaver root]# lspci 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:02.0 CardBus bridge: Texas Instruments PCI1251A 00:02.1 CardBus bridge: Texas Instruments PCI1251A 00:06.0 Multimedia audio controller: Cirrus Logic CS 4610/11 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) 01:00.0 VGA compatible controller: Neomagic Corporation [MagicMedia 256AV] (rev 20) 02:00.0 Ethernet controller: Linksys Fast Ethernet 10/100 (rev 11) and ... [root@beaver root]# lspci -n 00:00.0 Class 0600: 8086:7190 (rev 03) 00:01.0 Class 0604: 8086:7191 (rev 03) 00:02.0 Class 0607: 104c:ac1d 00:02.1 Class 0607: 104c:ac1d 00:06.0 Class 0401: 1013:6001 (rev 01) 00:07.0 Class 0680: 8086:7110 (rev 02) 00:07.1 Class 0101: 8086:7111 (rev 01) 00:07.2 Class 0c03: 8086:7112 (rev 01) 00:07.3 Class 0680: 8086:7113 (rev 02) 01:00.0 Class 0300: 10c8:0005 (rev 20) 02:00.0 Class 0200: 1317:1985 (rev 11) > > Region 0: I/O ports at 4800 [size=256] > > Region 1: Memory at 12c00000 (32-bit, non-prefetchable) [size=1K] > > > 14 packets transmitted, 3 received, 78% loss, time 13064ms > > rtt min/avg/max/mdev = 0.303/0.400/0.570/0.121 ms > > It's work a little bit... that narrows down the problem. Yes, I was being rather melodramatic. It is not completely dead. > That's curious! I'm guessing that there is an error message from the > CardBus code, likely earlier in the boot sequence. Nothing unusual seen. I could send you all of dmesg. > > eth0: ADMtek Centaur-C rev 17 at 0xd29ee000, EEPROM not present, > > 00:4C:69:6E:75:79, IRQ 11. > > This is a Bad Thing. The driver had to make up a station address. If > the EEPROM is really erased or missing, card-specific NIC parameters > have not been loaded. > > > eth0: MII transceiver #1 config 3100 status 7869 advertising 05e1. > > What does 'mii-diag' report? [root@beaver root]# mii-diag eth0 Basic registers of MII PHY #1: 1100 786d 001d 2411 05e1 41e1 0007 2001. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x1100: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. End of basic transceiver information. > > tulip-diag -eee reports: > > tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a ADMtek AL985 Centaur-C adapter at 0x4800. > > Comet duplex is reported in the MII status registers. > > Transmit started, Receive started. > > The Rx process state is 'Waiting for packets'. > > The Tx process state is 'Idle'. > > The transmit threshold is 128. > > Normal operation so far. > > > Comet MAC address registers 6e694c00 ffff7975 > > Comet multicast filter 0000000040000000. > > EEPROM 256 words, 8 address bits. > > WARNING: The EEPROM is missing or erased! > > Ethernet MAC Station Address ff:ff:ff:ff:ff:ff. > > Default connection type 'Default'. > > PCI IDs Vendor ffff Device ffff Subsystem ffff ffff > > Hmmm, something is wrong. The chip did manage to load the subsystem ID, > so part of the EEPROM is programmed. > > > I see similar issues posted on this list but I have not seen a > > solution. > > What similar issues? I haven't noticed another error report that matches > this one. I am referring to http://www.tux.org/hypermail/linux-tulip-bug/2002-Dec/0002.html wherein Mr Savage reported ... WARNING: The EEPROM is missing or erased! Seems to be similar, maybe not identical experience. On my system tulip-diag -aaemmf reports ... tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-C adapter at 0x4000. ADMtek AL985 Centaur-C chip registers at 0x4000: 0x00: fff98000 ffffffff ffffffff 1103e800 1103ea00 fc664010 ff972113 ffffffff 0x40: fffe0000 fffd97f8 00000000 fffe0000 00000000 00000200 00000000 00000008 Extended registers: 0x80: 2066c010 03fe7fff a05c0005 3c44ffff 00000000 1103ea00 1103e810 ffe0f000 0xa0: f0000000 6e694c00 ffff7975 00000000 40000000 00000000 00000000 00000000 0xc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0xe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 18000027 Comet duplex is reported in the MII status registers. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Comet MAC address registers 6e694c00 ffff7975 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. WARNING: The EEPROM is missing or erased! Ethernet MAC Station Address ff:ff:ff:ff:ff:ff. Default connection type 'Default'. PCI IDs Vendor ffff Device ffff Subsystem ffff ffff PCI min_grant 255 max_latency 255. CSR18 power-up setting 0xffff****. MII PHY found at address 1, status 0x7849. MII PHY #1 transceiver registers: 1100 7849 001d 2411 05e1 0000 0004 2001 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 20a8 205f 0000 011f 7490 0000 b080 6946 2c58 1326 8911 0444 0230 0000. -Robert -- Robert W March St. Andrew's House L'Orignal Ontario Canada From jarl@softace.dk Tue Jan 7 14:31:01 2003 From: jarl@softace.dk (Jarl Friis) Date: Tue Jan 7 14:31:01 2003 Subject: [tulip] FA511 not passing data In-Reply-To: <200301062306.45436.RWMarch@sympatico.ca> References: <200301062306.45436.RWMarch@sympatico.ca> Message-ID: Robert W March writes: > > and ... > > [root@beaver root]# lspci -n > 00:00.0 Class 0600: 8086:7190 (rev 03) > 00:01.0 Class 0604: 8086:7191 (rev 03) > 00:02.0 Class 0607: 104c:ac1d > 00:02.1 Class 0607: 104c:ac1d > 00:06.0 Class 0401: 1013:6001 (rev 01) > 00:07.0 Class 0680: 8086:7110 (rev 02) > 00:07.1 Class 0101: 8086:7111 (rev 01) > 00:07.2 Class 0c03: 8086:7112 (rev 01) > 00:07.3 Class 0680: 8086:7113 (rev 02) > 01:00.0 Class 0300: 10c8:0005 (rev 20) > 02:00.0 Class 0200: 1317:1985 (rev 11) please use 'lspci -n -v' this will give PCI IDS *and* subsystem numbers. It seems that an entry in pciids.sf.net needs updated. http://pciids.sourceforge.net/iii/?i=1317 Jarl From acbispo@altavista.se Tue Jan 7 23:13:02 2003 From: acbispo@altavista.se (acbispo@altavista.se) Date: Tue Jan 7 23:13:02 2003 Subject: [tulip] Re: NORTON SYSTEMWORKS 2003 CLEARANCE SALE! 2913Riaf4-253C-13 Message-ID: <002610c2ad14$dac11568$1158030c@kkqbksgj> jwlb gry *NEW-Special Package Deal!* Norton SystemWorks 2003 Software Suite -Professional Edition- ATTN: This is a MUST for ALL Computer Users!!! Includes Five - Feature-Packed Utilities...ALL For ONE Special LOW Price! -Norton AntiVirus 2003 -Norton Ghost 2003 -GoBack 3 Personal Edition -Norton Utilities 2003 -Norton CleanSweep 2003 This Software Will: - Protect your computer from unwanted and hazardous viruses - Help secure your private & valuable information - Allow you to transfer files and send e-mails safely - Backup your ALL your data quick and easily - Improve your PC's performance w/superior integral diagnostics! Six Feature-Packed Utilities...For One Great Price! A $300-Plus Combined Retail Value! YOURS for Only $39.99! (Includes **FREE** Shipping TOO!) Don't fall prey to destructive viruses or hackers! Protect your computer and your valuable information! CLICK HERE to Order Yours NOW! http://realapartment.com/norton/nsw15.htm *************************************************************** You are receiving this special offer because you have provided permission to receive third party email communications regarding special online promotions or offers. If you do not wish to receive any further messages from AB Network. http://www.realapartment.com/dvdps/ gry 1407RONj2-356SOCR0808svUU6-390LGCC4866OfvP1-l41 From jarl@softace.dk Wed Jan 8 02:40:00 2003 From: jarl@softace.dk (Jarl Friis) Date: Wed Jan 8 02:40:00 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: <200301072059.56716.RWMarch@sympatico.ca> References: <200301062306.45436.RWMarch@sympatico.ca> <200301072059.56716.RWMarch@sympatico.ca> Message-ID: I repost this to the list, as I think others will be interested. Robert W March writes: > On January 7, 2003 14:30, you wrote: > > Robert W March writes: > > > and ... > > > > > > [root@beaver root]# lspci -n > > > 00:00.0 Class 0600: 8086:7190 (rev 03) > > > 00:01.0 Class 0604: 8086:7191 (rev 03) > > > 00:02.0 Class 0607: 104c:ac1d > > > 00:02.1 Class 0607: 104c:ac1d > > > 00:06.0 Class 0401: 1013:6001 (rev 01) > > > 00:07.0 Class 0680: 8086:7110 (rev 02) > > > 00:07.1 Class 0101: 8086:7111 (rev 01) > > > 00:07.2 Class 0c03: 8086:7112 (rev 01) > > > 00:07.3 Class 0680: 8086:7113 (rev 02) > > > 01:00.0 Class 0300: 10c8:0005 (rev 20) > > > 02:00.0 Class 0200: 1317:1985 (rev 11) > > > > please use 'lspci -n -v' this will give PCI IDS *and* subsystem numbers. > > Hello Jarl, > > Here it is (the full output so that I do not leave out anything important): > [root@beaver root]# lspci -n -v > 00:00.0 Class 0600: 8086:7190 (rev 03) > Flags: bus master, medium devsel, latency 64 > Memory at 40000000 (32-bit, prefetchable) [size=64M] > Capabilities: [a0] AGP version 1.0 > > 00:01.0 Class 0604: 8086:7191 (rev 03) > Flags: bus master, 66Mhz, medium devsel, latency 168 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=176 > I/O behind bridge: 0000d000-0000dfff > Memory behind bridge: 70000000-dfffffff > Prefetchable memory behind bridge: e0000000-f7ffffff > > 00:02.0 Class 0607: 104c:ac1d > Subsystem: 1014:00eb > Flags: bus master, medium devsel, latency 168, IRQ 11 > Memory at 50102000 (32-bit, non-prefetchable) [size=4K] > Bus: primary=00, secondary=02, subordinate=04, sec-latency=176 > Memory window 0: 12000000-123ff000 (prefetchable) > Memory window 1: 12400000-127ff000 > I/O window 0: 00004000-000040ff > I/O window 1: 00004400-000044ff > 16-bit legacy interface ports at 0001 > > 00:02.1 Class 0607: 104c:ac1d > Subsystem: 1014:00eb > Flags: bus master, medium devsel, latency 168, IRQ 11 > Memory at 50101000 (32-bit, non-prefetchable) [size=4K] > Bus: primary=00, secondary=05, subordinate=07, sec-latency=176 > Memory window 0: 12800000-12bff000 (prefetchable) > Memory window 1: 12c00000-12fff000 > I/O window 0: 00004800-000048ff > I/O window 1: 00004c00-00004cff > 16-bit legacy interface ports at 0001 > > 00:06.0 Class 0401: 1013:6001 (rev 01) > Subsystem: 1014:1010 > Flags: bus master, medium devsel, latency 32, IRQ 11 > Memory at 50100000 (32-bit, non-prefetchable) [size=4K] > Memory at 50000000 (32-bit, non-prefetchable) [size=1M] > > 00:07.0 Class 0680: 8086:7110 (rev 02) > Flags: bus master, medium devsel, latency 0 > > 00:07.1 Class 0101: 8086:7111 (rev 01) (prog-if 80 [Master]) > Flags: bus master, medium devsel, latency 48 > [virtual] I/O ports at 01f0 > [virtual] I/O ports at 03f4 > [virtual] I/O ports at 0170 > [virtual] I/O ports at 0374 > I/O ports at fcf0 [size=16] > > 00:07.2 Class 0c03: 8086:7112 (rev 01) > Flags: bus master, medium devsel, latency 48, IRQ 11 > I/O ports at 8400 [size=32] > > 00:07.3 Class 0680: 8086:7113 (rev 02) > Flags: medium devsel, IRQ 9 > > 01:00.0 Class 0300: 10c8:0005 (rev 20) > Subsystem: 1014:00dd > Flags: bus master, medium devsel, latency 128, IRQ 11 > Memory at e0000000 (32-bit, prefetchable) [size=16M] > Memory at 70000000 (32-bit, non-prefetchable) [size=4M] > Memory at 70400000 (32-bit, non-prefetchable) [size=1M] > Capabilities: [dc] Power Management version 1 > > 02:00.0 Class 0200: 1317:1985 (rev 11) > Subsystem: 1385:511a > Flags: bus master, medium devsel, latency 64, IRQ 11 > I/O ports at 4000 [size=256] > Memory at 12400000 (32-bit, non-prefetchable) [size=1K] > Expansion ROM at 12000000 [size=128K] > Capabilities: [c0] Power Management version 2 Indeed 1385 is Netgear, though 1317 is linksys. It seems like we need a new entry on http://pciids.sourceforge.net/iii/?i=13171985 Donald, could you please on basis of diag and mii output add an entry on this one. Please note that ----------------------------------------- Real chip names and numbers are preferred over marketing names, in case you know both, please enclose the marketing name in angle brackets like in "3c595 100BaseTX [Vortex]" ----------------------------------------- Note further if you have multiple entries to add, it is easier to download the text file and send a diff. Yet, none of this solves the real problem. Jarl From jarl@softace.dk Wed Jan 8 03:49:01 2003 From: jarl@softace.dk (Jarl Friis) Date: Wed Jan 8 03:49:01 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: References: <200301062306.45436.RWMarch@sympatico.ca> <200301072059.56716.RWMarch@sympatico.ca> Message-ID: Jarl Friis writes: > I repost this to the list, as I think others will be interested. > > Robert W March writes: > > > 02:00.0 Class 0200: 1317:1985 (rev 11) > > Subsystem: 1385:511a > > Flags: bus master, medium devsel, latency 64, IRQ 11 > > I/O ports at 4000 [size=256] > > Memory at 12400000 (32-bit, non-prefetchable) [size=1K] > > Expansion ROM at 12000000 [size=128K] > > Capabilities: [c0] Power Management version 2 > > Indeed 1385 is Netgear, though 1317 is linksys. > It seems like we need a new entry on > http://pciids.sourceforge.net/iii/?i=13171985 I just added this emtry myself based on info provided by Robert W March and Jeremiah Savage Jarl From becker@scyld.com Wed Jan 8 10:15:01 2003 From: becker@scyld.com (Donald Becker) Date: Wed Jan 8 10:15:01 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: Message-ID: On 8 Jan 2003, Jarl Friis wrote: > Subject: Re: [tulip] FA511 not passing much data > > Indeed 1385 is Netgear, though 1317 is linksys. > > > 02:00.0 Class 0200: 1317:1985 (rev 11) > > > Subsystem: 1385:511a Huh? Where did you get the idea that PCI vendor 1317 is Linksys? This is a ADMtek Comet '985 chip, implemented on a NetGear card. There are several other Ethernet NIC chips in the Centuar/Comet series with 0x1317 ID, generally with the format [01]98[135] or 951? > > It seems like we need a new entry on > > http://pciids.sourceforge.net/iii/?i=13171985 > > I just added this emtry myself based on info provided by Robert W > March and Jeremiah Savage -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From RWMarch@sympatico.ca Wed Jan 8 10:17:02 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Wed Jan 8 10:17:02 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: References: <200301062306.45436.RWMarch@sympatico.ca> Message-ID: <200301072059.56716.RWMarch@sympatico.ca> On January 7, 2003 14:30, you wrote: > Robert W March writes: > > and ... > > > > [root@beaver root]# lspci -n > > 00:00.0 Class 0600: 8086:7190 (rev 03) > > 00:01.0 Class 0604: 8086:7191 (rev 03) > > 00:02.0 Class 0607: 104c:ac1d > > 00:02.1 Class 0607: 104c:ac1d > > 00:06.0 Class 0401: 1013:6001 (rev 01) > > 00:07.0 Class 0680: 8086:7110 (rev 02) > > 00:07.1 Class 0101: 8086:7111 (rev 01) > > 00:07.2 Class 0c03: 8086:7112 (rev 01) > > 00:07.3 Class 0680: 8086:7113 (rev 02) > > 01:00.0 Class 0300: 10c8:0005 (rev 20) > > 02:00.0 Class 0200: 1317:1985 (rev 11) > > please use 'lspci -n -v' this will give PCI IDS *and* subsystem numbers. Hello Jarl, Here it is (the full output so that I do not leave out anything important): [root@beaver root]# lspci -n -v 00:00.0 Class 0600: 8086:7190 (rev 03) Flags: bus master, medium devsel, latency 64 Memory at 40000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 Class 0604: 8086:7191 (rev 03) Flags: bus master, 66Mhz, medium devsel, latency 168 Bus: primary=00, secondary=01, subordinate=01, sec-latency=176 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: 70000000-dfffffff Prefetchable memory behind bridge: e0000000-f7ffffff 00:02.0 Class 0607: 104c:ac1d Subsystem: 1014:00eb Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 50102000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=04, sec-latency=176 Memory window 0: 12000000-123ff000 (prefetchable) Memory window 1: 12400000-127ff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 00:02.1 Class 0607: 104c:ac1d Subsystem: 1014:00eb Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 50101000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=05, subordinate=07, sec-latency=176 Memory window 0: 12800000-12bff000 (prefetchable) Memory window 1: 12c00000-12fff000 I/O window 0: 00004800-000048ff I/O window 1: 00004c00-00004cff 16-bit legacy interface ports at 0001 00:06.0 Class 0401: 1013:6001 (rev 01) Subsystem: 1014:1010 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at 50100000 (32-bit, non-prefetchable) [size=4K] Memory at 50000000 (32-bit, non-prefetchable) [size=1M] 00:07.0 Class 0680: 8086:7110 (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 Class 0101: 8086:7111 (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 48 [virtual] I/O ports at 01f0 [virtual] I/O ports at 03f4 [virtual] I/O ports at 0170 [virtual] I/O ports at 0374 I/O ports at fcf0 [size=16] 00:07.2 Class 0c03: 8086:7112 (rev 01) Flags: bus master, medium devsel, latency 48, IRQ 11 I/O ports at 8400 [size=32] 00:07.3 Class 0680: 8086:7113 (rev 02) Flags: medium devsel, IRQ 9 01:00.0 Class 0300: 10c8:0005 (rev 20) Subsystem: 1014:00dd Flags: bus master, medium devsel, latency 128, IRQ 11 Memory at e0000000 (32-bit, prefetchable) [size=16M] Memory at 70000000 (32-bit, non-prefetchable) [size=4M] Memory at 70400000 (32-bit, non-prefetchable) [size=1M] Capabilities: [dc] Power Management version 1 02:00.0 Class 0200: 1317:1985 (rev 11) Subsystem: 1385:511a Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 4000 [size=256] Memory at 12400000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at 12000000 [size=128K] Capabilities: [c0] Power Management version 2 > It seems that an entry in pciids.sf.net needs updated. > http://pciids.sourceforge.net/iii/?i=1317 > > Jarl -Robert -- Robert W March St. Andrew's House L'Orignal Ontario Canada From RWMarch@sympatico.ca Wed Jan 8 14:31:02 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Wed Jan 8 14:31:02 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: References: Message-ID: <200301081108.49110.RWMarch@sympatico.ca> Donald, Is there any other information that I could provide to you or testing that I could run to help get this card running properly? -Robert -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From jarl@softace.dk Thu Jan 9 02:32:01 2003 From: jarl@softace.dk (Jarl Friis) Date: Thu Jan 9 02:32:01 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: References: Message-ID: Donald Becker writes: > On 8 Jan 2003, Jarl Friis wrote: > > > Subject: Re: [tulip] FA511 not passing much data > > > > Indeed 1385 is Netgear, though 1317 is linksys. > > > > 02:00.0 Class 0200: 1317:1985 (rev 11) > > > > Subsystem: 1385:511a > > Huh? Where did you get the idea that PCI vendor 1317 is Linksys? >From http://pciids.sourceforge.net/iii/?i=1317 But of course that may be wrong. Do you know the correct PCI ID of linksys? > This is a ADMtek Comet '985 chip, implemented on a NetGear card. Very well, but it seems to be branded under linksys' PCI ID, right? > There are several other Ethernet NIC chips in the Centuar/Comet series > with 0x1317 ID, generally with the format [01]98[135] or 951? I have added the entry 1385:511a on http://pciids.sourceforge.net/iii/?i=13171985 Do you disagree on this? Jarl From becker@scyld.com Thu Jan 9 16:17:02 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 9 16:17:02 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: Message-ID: On 9 Jan 2003, Jarl Friis wrote: > Donald Becker writes: > > > On 8 Jan 2003, Jarl Friis wrote: > > > > > Subject: Re: [tulip] FA511 not passing much data > > > > > > Indeed 1385 is Netgear, though 1317 is linksys. > > > > > 02:00.0 Class 0200: 1317:1985 (rev 11) > > > > > Subsystem: 1385:511a > > > > Huh? Where did you get the idea that PCI vendor 1317 is Linksys? > > >From http://pciids.sourceforge.net/iii/?i=1317 > But of course that may be wrong. Do you know the correct PCI ID of > linksys? A board reseller isn't required to have an ID, only the people making the PCI chips. A PCI device must have an ID, and may optionally have a subsystem ID. The board vendor typically programs the subsystem ID with their own values, although a few chips allow the configuration EEPROM to also override the chip's standard PCI ID. The motivation to do this is to appear to have a unique product, for instance when the vendor doesn't want the customer to know that "$80 value" NIC is exactly the same a $6 generic rtl8139 board. Actually, the vendor ID is more general than just PCI devices. Many other devices (e.g. USB) now use a 16+16 bit Vendor/Device ID. Much like the 2+22+24 bit IEEE station address, this kind of standardization is a very good thing. > > This is a ADMtek Comet '985 chip, implemented on a NetGear card. > > Very well, but it seems to be branded under linksys' PCI ID, right? No. The list that Linux uses was apparently user-submitted guesses. And once there is an entry, it is never validated. > > There are several other Ethernet NIC chips in the Centuar/Comet series > > with 0x1317 ID, generally with the format [01]98[135] or 951? > > I have added the entry 1385:511a on > http://pciids.sourceforge.net/iii/?i=13171985 > Do you disagree on this? The 1385:511a is the subsystem ID for the Netgear FA511, which should always use the 1317:1985 ADMtek Comet/Centaur chip. This is similar to the 1385:f311 (subsystem ID) Netgear FA311 v1 board, which always uses the 100B:0020 (primary ID) National Semiconductor DP83815 chip. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From jarl@softace.dk Fri Jan 10 02:32:01 2003 From: jarl@softace.dk (Jarl Friis) Date: Fri Jan 10 02:32:01 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: References: Message-ID: Donald Becker writes: > On 9 Jan 2003, Jarl Friis wrote: > > A board reseller isn't required to have an ID, only the people making > the PCI chips. A PCI device must have an ID, and may optionally have a > subsystem ID. > > The board vendor typically programs the subsystem ID with their own > values, although a few chips allow the configuration EEPROM to also > override the chip's standard PCI ID. The motivation to do this is to > appear to have a unique product, for instance when the vendor doesn't > want the customer to know that "$80 value" NIC is exactly the same a $6 > generic rtl8139 board. Thank you *very* much for clearing these things up. I always wondered how those numbers were intended to be used. Do you have any URL on documents describing these usage information? So in short one can think of the main PCIID as the hardware/chip identifier ment for technicians (driver developers), whereas the subsystem ID is for branding, marketing and value added resellers. Is that correct? > Actually, the vendor ID is more general than just PCI devices. Many > other devices (e.g. USB) now use a 16+16 bit Vendor/Device ID. Much > like the 2+22+24 bit IEEE station address, this kind of standardization > is a very good thing. I don't know anything about 2+22+24 bit IEEE station address, but it seems good that the same 16+16 bit system is used for USB devices. > No. The list that Linux uses was apparently user-submitted guesses. > And once there is an entry, it is never validated. I will mail the pci.ids maintainer about this issues and talk to him about things. Thank you very much. The list is never validated, but it is not too difficult to update with more correct information. > > > There are several other Ethernet NIC chips in the Centuar/Comet series > > > with 0x1317 ID, generally with the format [01]98[135] or 951? > > > > I have added the entry 1385:511a on > > http://pciids.sourceforge.net/iii/?i=13171985 > > Do you disagree on this? > > The 1385:511a is the subsystem ID for the Netgear FA511, which should > always use the 1317:1985 ADMtek Comet/Centaur chip. > > This is similar to the 1385:f311 (subsystem ID) Netgear FA311 v1 board, > which always uses the 100B:0020 (primary ID) National Semiconductor > DP83815 chip. Thank you very much for giving such a concrete example. So what you are saying is that the entry for the main PCI ID 1317:1985 should actually be "Comet/Centaur chip" opposed to "Fast Ethernet 10/100" as it is now, do I get this correct? And in subsystem entry 1317:1985-1385:511a There should be "NETGEAR FA511" and not "ADMtek AL985 Centaur-C [NETGEAR FA511]" as I have submitted for now, correct? Further the entry 100B:0020 should be "DP83815" opposed to "DP83815 (MacPhyter) Ethernet Controller" and 100B:0020-1385:f311 should be "NETGEAR FA311" which is missing now. Do you have any comments on the fact that the list currently contains "FA311" for the main PCI ID entry 1385:f311 ? or is this yet another users that have incorrectly entered a subsystem ID into a main ID's entry? Jarl From eshwayri@nc.rr.com Fri Jan 10 08:20:01 2003 From: eshwayri@nc.rr.com (Edmond E. Shwayri) Date: Fri Jan 10 08:20:01 2003 Subject: [tulip] tulip-diag updating EEPROM on Osicom Message-ID: <4.3.2.7.2.20030110005442.02ad21b0@pop-server.nc.rr.com> I ran into an interesting "problem" and I was hoping someone would have an answer. First the history : I have an Osicom 4 port card. I have used the card in Linux for a few years now. It has worked well. 6 months ago I hooked up a hub to one of the Osicom ports and I found that the "Autosense" wasn't working right. Since the hub is un-managed I decided to change the setting on the Osicom. Using tulip-diag I changed the media from 800 to 203 for 3 of the ports - I forget why I left the fourth alone. It worked as long as the hub was turned on AFTER the Osicom. It was irritating so a few months later I got a managed Cisco switch (already ahve one) and it worked fine. I didn't bother to switch the eeprom back to 800 since everything was working fine. Recently I decided to upgrade the computer from an old lowly Pentium to a new dual AMD. For maintenance I decided I would also install Windows 2000 in a dual boot. When I inserted the Osicom card, Windows detected all 4 ports and installed drivers. While all 4 ports were detected, only one was marked as working. The others had the "this device can't be started" and the yellow bang. I noticed that the one port that it was happy with was the one port I had NOT changed with tulip-diag. I booted into Linux and asked tulip-diag to dump out the eeprom for the 4 ports. The port that was working looked like this : tulip-diag.c:v2.09 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #2: Found a Digital DS21140 Tulip adapter at 0xa400. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 0000, device 0000. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:BC:11:11:0A. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0800 (Autosense). CSR12 direction setting bits 0x0f. 4 transceiver description blocks: 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 0x01, command 00 0x8e. Media detection by looking for a 0 on bit 7 of the CSR12 control port. 21140 Non-MII transceiver for media 3 (100baseTx). CSR12 control port setting 0x01, command 00 0x6d. Media detection by looking for a 1 on bit 6 of the CSR12 control port. 21140 Non-MII transceiver for media 4 (10baseT-Full Duplex). CSR12 control port setting 0x09, command 00 0x8e. Media detection by looking for a 0 on bit 7 of the CSR12 control port. 21140 Non-MII transceiver for media 5 (100baseTx Full Duplex). CSR12 control port setting 0x01, command 00 0x6d. Media detection by looking for a 1 on bit 6 of the CSR12 control port. EEPROM contents (64 words): 0x00: 0000 0000 0000 0000 0000 0000 0000 0000 0x08: 0000 0101 0000 11bc 0a11 1e00 0000 0800 0x10: 040f 0100 008e 0103 006d 0904 008e 0105 0x18: 006d 0100 0000 0000 3412 4000 3412 4000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 2d5d ID block CRC 0xe3 (vs. 00). Full contents CRC 0x2d5d (read as 0x2d5d). The one port that was not working looked like : tulip-diag.c:v2.09 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xa000. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 0000, device 0000. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:BC:11:11:09. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0203 (100baseTx). CSR12 direction setting bits 0x0f. 4 transceiver description blocks: 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 0x01, command 00 0x8e. Media detection by looking for a 0 on bit 7 of the CSR12 control port. 21140 Non-MII transceiver for media 3 (100baseTx). CSR12 control port setting 0x01, command 00 0x6d. Media detection by looking for a 1 on bit 6 of the CSR12 control port. 21140 Non-MII transceiver for media 4 (10baseT-Full Duplex). CSR12 control port setting 0x09, command 00 0x8e. Media detection by looking for a 0 on bit 7 of the CSR12 control port. 21140 Non-MII transceiver for media 5 (100baseTx Full Duplex). CSR12 control port setting 0x01, command 00 0x6d. Media detection by looking for a 1 on bit 6 of the CSR12 control port. EEPROM contents (64 words): 0x00: 0000 0000 0000 0000 0000 0000 0000 0000 0x08: 0000 0101 0000 11bc 0911 1e00 0000 0203 0x10: 040f 0100 008e 0103 006d 0904 008e 0105 0x18: 006d 0100 0000 0000 3412 4000 3412 4000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 bb5d ID block CRC 0xe3 (vs. 00). Full contents CRC 0x29e0 (read as 0xbb5d). So, I used tulip-diag and told that port to switch from 203 back 800 for media (its original setting before I played with it). Once I did that the tulip-diag after the change was : tulip-diag.c:v2.09 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xa000. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 0000, device 0000. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:BC:11:11:09. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0800 (Autosense). CSR12 direction setting bits 0x0f. 4 transceiver description blocks: 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 0x01, command 00 0x8e. Media detection by looking for a 0 on bit 7 of the CSR12 control port. 21140 Non-MII transceiver for media 3 (100baseTx). CSR12 control port setting 0x01, command 00 0x6d. Media detection by looking for a 1 on bit 6 of the CSR12 control port. 21140 Non-MII transceiver for media 4 (10baseT-Full Duplex). CSR12 control port setting 0x09, command 00 0x8e. Media detection by looking for a 0 on bit 7 of the CSR12 control port. 21140 Non-MII transceiver for media 5 (100baseTx Full Duplex). CSR12 control port setting 0x01, command 00 0x6d. Media detection by looking for a 1 on bit 6 of the CSR12 control port. EEPROM contents (64 words): 0x00: 0000 0000 0000 0000 0000 0000 0000 0000 0x08: 0000 0101 0000 11bc 0911 1e00 0000 0800 0x10: 040f 0100 008e 0103 006d 0904 008e 0105 0x18: 006d 0100 0000 0000 3412 4000 3412 4000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 bb5d ID block CRC 0xe3 (vs. 00). Full contents CRC 0xbb5d (read as 0xbb5d). So, I rebooted into Windows and now I had two working ports instead of 1. I went back into Linux and changed the other 2 ports as well and now all 4 ports show up as working. The question is why? Could be the auto-sense / fixed media; however, what is more striking is the Full Contents CRC. Before the switch back to the original 800 : Full contents CRC 0x29e0 (read as 0xbb5d). After the switch : Full contents CRC 0xbb5d (read as 0xbb5d). So, what it looks like is that tulip-diag doesn't change the CRC when it updates a setting. The Windows driver could very well be looking at the CRC and saying, ooops corrupt eeprom - don't load port. Isn't there any way to update CRC when one updates a setting? From becker@scyld.com Fri Jan 10 08:24:00 2003 From: becker@scyld.com (Donald Becker) Date: Fri Jan 10 08:24:00 2003 Subject: [tulip] FA511 not passing much data In-Reply-To: Message-ID: On 10 Jan 2003, Jarl Friis wrote: > Donald Becker writes: > > On 9 Jan 2003, Jarl Friis wrote: > > > > A board reseller isn't required to have an ID, only the people making > > the PCI chips. A PCI device must have an ID, and may optionally have a > > subsystem ID. ... > Thank you *very* much for clearing these things up. I always wondered > how those numbers were intended to be used. Do you have any URL on > documents describing these usage information? Hmmm, URL... no. The standards documents are very precise, in a not a not immediately descriptive way. The book I typically grab for PCI questions is "PCI System Architecture". (That series of book is somehow useful, concise and accurate while still feeling badly written and repetitive.) > So in short one can think of the main PCIID as the hardware/chip > identifier ment for technicians (driver developers), whereas the > subsystem ID is for branding, marketing and value added resellers. Is > that correct? Yes. To put a MS-Windows-centric spin on it: a vendor wants MS to do all of the work validating and updating a driver that works with the chip (based on the PCI ID), yet still show the vendor's name when the card is detected as if the vendor wrote the driver (based on the Subsystem ID). > I don't know anything about 2+22+24 bit IEEE station address, but it > seems good that the same 16+16 bit system is used for USB devices. The first three bytes of the "Ethernet station address" identify the NIC vendor, with the vendor assigning the remaining three bytes in a "dense" manner (presumably sequentially). Each address block costs a few kilo-$. Some vendors, such as 3Com and Intel, have shipped so many devices that they have multiple three byte prefixs. > > No. The list that Linux uses was apparently user-submitted guesses. > > And once there is an entry, it is never validated. > > I will mail the pci.ids maintainer about this issues and talk to him > about things. Thank you very much. The list is never validated, but it > is not too difficult to update with more correct information. One problem is when the name is put into the kernel. Now the kernel is wrong for all time. Now for the _important_ question: How does the affect Donald Becker? I get a bunch of email where people insist that my driver and diagnostic code is broken based on the name mismatch. > So what you are saying is that the entry for the main PCI ID 1317:1985 > should actually be "Comet/Centaur chip" opposed to "Fast > Ethernet 10/100" as it is now, do I get this correct? Yes. 1317 == ADMtek 1317:1985 == ADMtek Centaur-C 10/100 Ethernet > And in subsystem entry 1317:1985-1385:511a There should be "NETGEAR > FA511" and not "ADMtek AL985 Centaur-C [NETGEAR FA511]" as I have > submitted for now, correct? Correct. > Further the entry 100B:0020 should be "DP83815" opposed to "DP83815 > (MacPhyter) Ethernet Controller" Perhaps correct. I've only seen the name 'MacPhyter' from the table. I'm not certain that it's correct. But if it is correct, the only problem I have with the current entry is that the "Ethernet Controller" phrase is inconsistent with other entries. and 100B:0020-1385:f311 should be > "NETGEAR FA311" which is missing now. Correct. > Do you have any comments on the fact that the list currently contains > "FA311" for the main PCI ID entry 1385:f311 ? or is this yet another > users that have incorrectly entered a subsystem ID into a main ID's entry? Perhaps should say "Netgear FA311"; there should be some consistency with repeating the vendor name. There should never be a conflict between primary and subsystem IDs -- there only needs to be a single database. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri Jan 10 08:50:00 2003 From: becker@scyld.com (Donald Becker) Date: Fri Jan 10 08:50:00 2003 Subject: [tulip] tulip-diag updating EEPROM on Osicom In-Reply-To: <4.3.2.7.2.20030110005442.02ad21b0@pop-server.nc.rr.com> Message-ID: On Fri, 10 Jan 2003, Edmond E. Shwayri wrote: > I ran into an interesting "problem" and I was hoping someone would have an > answer. First the history : > > I have an Osicom 4 port card. I have used the card in Linux for a few > years now. It has worked well. 6 months ago I hooked up a hub to one of > the Osicom ports and I found that the "Autosense" wasn't working > right. What driver version? What was the detection message? ... > asked tulip-diag to dump out the eeprom for the 4 ports. The port that was > working looked like this : > > tulip-diag.c:v2.09 1/28/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #2: Found a Digital DS21140 Tulip adapter at 0xa400. ... > Leaf node at offset 30, default media type 0800 (Autosense). ... > 21140 Non-MII transceiver for media 3 (100baseTx). > CSR12 control port setting 0x01, command 00 0x6d. > Media detection by looking for a 1 on bit 6 of the CSR12 control port. OK, you have a 21140 with a SYM transceiver. This is an old board cannot do autonegotiation. By default the driver should sense the link speed and switch to that media type in standard (half duplex) mode. > The one port that was not working looked like : > > tulip-diag.c:v2.09 1/28/2002 Donald Becker (becker@scyld.com) > Index #1: Found a Digital DS21140 Tulip adapter at 0xa000. > Leaf node at offset 30, default media type 0203 (100baseTx). What was the driver detection message? > So, I used tulip-diag and told that port to switch from 203 back 800 for > media (its original setting before I played with it). Once I did that the > tulip-diag after the change was : The interface must be up for the link selection to take place. > all 4 ports show up as working. The question is why? Could be the > auto-sense / fixed media; however, what is more striking is the Full > Contents CRC. > Before the switch back to the original 800 : > Full contents CRC 0x29e0 (read as 0xbb5d). > After the switch : > Full contents CRC 0xbb5d (read as 0xbb5d). > So, what it looks like is that tulip-diag doesn't change the CRC when it > updates a setting. The Windows driver could very well be looking at the > CRC and saying, ooops corrupt eeprom - don't load port. Isn't there any > way to update CRC when one updates a setting? The 'tulip-diag' does not update the CRC. Some boards don't follow the defined format, and it seems safer to only change the single specific field that the user requests. It would be easy to add the code to write the CRC only if the previous value was correct, but I'll have to think if this might break other boards. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From dclark@akamail.com Sun Jan 12 07:47:00 2003 From: dclark@akamail.com (Duane Clark) Date: Sun Jan 12 07:47:00 2003 Subject: [tulip] Problem with ADMtek Centaur-P Message-ID: <3E207A1C.7000102@akamail.com> Howdy, I have a problem with my computer randomly locking up hard after a recent kernel upgrade (to RH 7.3, kernel 2.4.18-18, compiled). For various reasons not important at the moment (I don't think) I suspect this to be due to the ethernet interface. So I figured I would try the latest tulip driver. My computer has two ethernet cards. They both come up with the stock tulip driver, but only the first comes up with the latest tulip driver. I have confirmed that simply swapping the tulip.o file between the versions (I saved the old one) alone determines whether the second card comes up. Here is a snip from dmesg with the stock tulip driver. pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.com/linux/drivers.html Linux Tulip driver version 0.9.15-pre11 (May 11, 2002) PCI: Enabling device 00:0d.0 (0384 -> 0387) PCI: Found IRQ 11 for device 00:0d.0 PCI: Sharing IRQ 11 with 00:09.1 PCI: Sharing IRQ 11 with 01:00.0 eth0: Lite-On PNIC-II rev 37 at 0xb800, 00:A0:CC:E5:4D:82, IRQ 11. PCI: Enabling device 00:0e.0 (0014 -> 0017) PCI: Assigned IRQ 10 for device 00:0e.0 PCI: Sharing IRQ 10 with 00:05.0 PCI: Sharing IRQ 10 with 00:07.0 PCI: Sharing IRQ 10 with 00:09.2 eth1: ADMtek Comet rev 17 at 0xb400, 00:20:78:04:1C:53, IRQ 10. And here is the same section with the latest driver. Pretty much everything in dmesg prior to this point is identical. pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.com/linux/drivers.html tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html The PCI BIOS has not enabled the device at 0/104! Updating PCI command 0384->0386. eth0: Lite-On LC82C115 PNIC-II rev 37 at 0xf8995000, 00:A0:CC:E5:4D:82, IRQ 11. PCI device 'ADMtek Centaur-P' was not assigned an IRQ. It will not be activated. From jim.smith.nl@sympatico.ca Mon Jan 13 14:56:01 2003 From: jim.smith.nl@sympatico.ca (jim.smith.nl@sympatico.ca) Date: Mon Jan 13 14:56:01 2003 Subject: [tulip] Errors compiling tulip driver - help needed Message-ID: <20030113195521.KQHI20334.tomts20-srv.bellnexxia.net@[209.226.175.18]> Hi listers, this is my first post to the list. I'm a newby when it comes to compiling anything other than the Linux kernel. Please bare when me. I have a Linksys 10/100 Mbps Network card in my computer. I am running Slackware Linux with kernel 2.4.18. I have downloaded files Makefile, kern_compat.h, pci-scan.c, pci-scan.h and tulip.c from ftp.scyld.com into a work directory. I then submitted the compile command like so : root@john:~/drivers/nic/linksys/work# gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall -Wstrict-prototype s -O6 -c tulip.c `[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS` I immediately get the following errors : [truncated output] /usr/include/asm/pci.h: At top level: /usr/include/asm/pci.h:101: parse error before `size_t' /usr/include/asm/pci.h:102: warning: function declaration isn't a prototype /usr/include/asm/pci.h: In function `pci_map_page': /usr/include/asm/pci.h:103: `direction' undeclared (first use in this function) /usr/include/asm/pci.h:106: `page' undeclared (first use in this function) /usr/include/asm/pci.h:106: `offset' undeclared (first use in this function) /usr/include/asm/pci.h:107: warning: control reaches end of non-void function /usr/include/asm/pci.h: At top level: /usr/include/asm/pci.h:110: parse error before `size_t' /usr/include/asm/pci.h:111: warning: function declaration isn't a prototype /usr/include/asm/pci.h: In function `pci_unmap_page': /usr/include/asm/pci.h:112: `direction' undeclared (first use in this function) /usr/include/asm/pci.h: At top level: /usr/include/asm/pci.h:190: parse error before `size_t' /usr/include/asm/pci.h:191: warning: function declaration isn't a prototype /usr/include/asm/pci.h: In function `pci_dma_sync_single': /usr/include/asm/pci.h:192: `direction' undeclared (first use in this function) /usr/include/asm/pci.h: At top level: /usr/include/asm/pci.h:255: parse error before `size_t' /usr/include/asm/pci.h:256: warning: function declaration isn't a prototype In file included from /usr/include/linux/highmem.h:5, from /usr/include/linux/skbuff.h:27, from /usr/include/linux/netdevice.h:146, from tulip.c:162: /usr/include/asm/pgalloc.h: In function `flush_tlb_mm': /usr/include/asm/pgalloc.h:183: dereferencing pointer to incomplete type /usr/include/asm/pgalloc.h: In function `flush_tlb_page': /usr/include/asm/pgalloc.h:190: dereferencing pointer to incomplete type /usr/include/asm/pgalloc.h: In function `flush_tlb_range': /usr/include/asm/pgalloc.h:197: dereferencing pointer to incomplete type In file included from /usr/include/linux/netdevice.h:146, from tulip.c:162: /usr/include/linux/skbuff.h: At top level: /usr/include/linux/skbuff.h:136: field `stamp' has incomplete type tulip.c: In function `strnlen': /usr/include/asm/string.h:431: warning: `__res' might be used uninitialized in this function tulip.c: At top level: /usr/include/linux/coda.h:261: storage size of `va_atime' isn't known /usr/include/linux/coda.h:262: storage size of `va_mtime' isn't known /usr/include/linux/coda.h:263: storage size of `va_ctime' isn't known /usr/include/linux/coda.h:566: storage size of `attr' isn't known /usr/include/linux/fs.h:529: storage size of `f_owner' isn't known /usr/include/linux/reiserfs_fs_sb.h:303: storage size of `j_dummy_inode' isn't known /usr/include/linux/reiserfs_fs_sb.h:305: storage size of `j_journal_list' isn't known /usr/include/linux/sched.h:361: storage size of `times' isn't known root@john:~/drivers/nic/linksys/work# I know that the output is suppose to go to /lib/modules/2.4.18/net/tulip.o but there is nothing there! I have a feeling that I am missing something really simple. Any help is greatly appreciated, Jim. From unixguy@verizonmail.com Mon Jan 13 23:39:01 2003 From: unixguy@verizonmail.com (unix guy) Date: Mon Jan 13 23:39:01 2003 Subject: [tulip] need driver for hawking pn672tx pcmcia ethernet card Message-ID: <20030114043744.22970.qmail@verizonmail.com> Does the tulip driver work for this? I get the following error. 'eth-pcmcia-0' has STARTMODE=hotplug: -> skipped As we are called from rcnetwork we do not set it up, because it was not set up manually or by hotplug before. What does this mean? Is this a driver issue or a configuration issue? Any help is greatly appreciated. Thanks, -Tired unix guy -- _______________________________________________ Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free! http://www.net2phone.com/cgi-bin/link.cgi?143 From becker@scyld.com Tue Jan 14 15:51:01 2003 From: becker@scyld.com (Donald Becker) Date: Tue Jan 14 15:51:01 2003 Subject: [tulip] need driver for hawking pn672tx pcmcia ethernet card In-Reply-To: <20030114043744.22970.qmail@verizonmail.com> Message-ID: On Mon, 13 Jan 2003, unix guy wrote: > Subject: [tulip] need driver for hawking pn672tx pcmcia ethernet card > > Does the tulip driver work for this? There is no way to tell if you driver problem. It's pretty clear that you have a non-driver configuration problem. > I get the following error. > 'eth-pcmcia-0' has STARTMODE=hotplug: -> skipped > As we are called from rcnetwork we do not set it up, because it was > not set up manually or by hotplug before. This is a problem with your distribution and configuration, not a driver problem. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue Jan 14 15:56:00 2003 From: becker@scyld.com (Donald Becker) Date: Tue Jan 14 15:56:00 2003 Subject: [tulip] Errors compiling tulip driver - help needed In-Reply-To: <20030113195521.KQHI20334.tomts20-srv.bellnexxia.net@[209.226.175.18]> Message-ID: On Mon, 13 Jan 2003 jim.smith.nl@sympatico.ca wrote: > this is my first post to the list. I'm a newby when it comes > to compiling anything other than the Linux kernel. Please bare > when me. I have a Linksys 10/100 Mbps Network card in my computer. > I am running Slackware Linux with kernel 2.4.18. I have downloaded > files Makefile, kern_compat.h, pci-scan.c, pci-scan.h and tulip.c > from ftp.scyld.com into a work directory. I then submitted the > compile command like so : > > root@john:~/drivers/nic/linksys/work# > gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall -Wstrict-prototype > s -O6 -c tulip.c `[ -f /usr/include/linux/modversions.h ] && > echo -DMODVERSIONS` > > I immediately get the following errors : > > [truncated output] > /usr/include/asm/pci.h: At top level: > /usr/include/asm/pci.h:101: parse error before `size_t' The errors before this are the important ones. Try compiling using the Makefile. It should tell you if anything (e.g. header files) is missing. mkdir /tmp/netdrivers/ cd /tmp/netdrivers/ ncftpget ftp://ftp.scyld.com/pub/network/netdrivers.tgz tar xfvz netdrivers.tgz make make install -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From RWMarch@sympatico.ca Wed Jan 15 06:59:02 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Wed Jan 15 06:59:02 2003 Subject: [tulip] NetGear FA511 PC Card Message-ID: <200301142355.59518.RWMarch@sympatico.ca> Has anyone been successful with this card on Linux? So far, my experience has been as follows: I installed one on a Thinkpad running RedHat and the 2.4.18 kernel. I have managed to get the tulip driver module to load against this kernel using Donald Becker's netdrivers.tgz package. All the elements of the driver package compiled and installed without error (well, except for cb_shim.o - unresolved symbols, but I suspect that is not material). insmod tulip loads without error and /var/log/messages reports ... Jan 14 23:13:47 localhost kernel: tulip.c:v0.95f 11/17/2002 Written by Donald Becker Jan 14 23:13:47 localhost kernel: http://www.scyld.com/network/tulip.html Jan 14 23:13:47 localhost kernel: eth0: ADMtek Centaur-C rev 17 at 0xd286b000, 00:4C:69:6E:75:79, IRQ 11. Jan 14 23:13:47 localhost kernel: eth0: MII transceiver #1 config 1100 status 786d advertising 05e1. Jan 14 23:13:47 localhost /etc/hotplug/net.agent: invoke ifup eth0 And ifconfig shows ... eth0 Link encap:Ethernet HWaddr 00:4C:69:6E:75:79 inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:168 (168.0 b) Interrupt:11 Base address:0xb000 But, ping fails. And tulip-diag reports ... tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-C adapter at 0x4800. Comet duplex is reported in the MII status registers. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Comet MAC address registers 6e694c00 ffff7975 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. WARNING: The EEPROM is missing or erased! Ethernet MAC Station Address ff:ff:ff:ff:ff:ff. Default connection type 'Default'. PCI IDs Vendor ffff Device ffff Subsystem ffff ffff PCI min_grant 255 max_latency 255. CSR18 power-up setting 0xffff****. EEPROM contents (256 words): 0x00: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x08: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x10: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x18: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x20: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x28: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x30: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x38: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x40: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x48: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x50: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x58: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x60: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x68: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x70: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x78: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x80: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x88: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x90: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x98: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xa0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xa8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xb0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xb8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xc0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xc8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xd0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xd8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xf8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ ID block CRC 0xfa (vs. 0xff). Full contents CRC 0x6a15 (read as 0xffff). Although on the very first occasion after the driver build when I did modprobe tulip, the diagnostic reported values for the eeprom. But not on any attempt since then have I seen eeprom values reported, unfortunately. Now tulip-diag always report as per the above. mii-diag -vvv reports ... mii-diag.c:v2.07 11/15/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. Using the new SIOCGMIIPHY value on PHY 1 (BMCR 0x3100). The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3100: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. End of basic transceiver information. MII PHY #1 transceiver registers: 3100 786d 001d 2411 05e1 41e1 0007 2001 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 2094 021c 0000 000f 7490 0000 b68f 6e17 325f 1529 8913 0450 0230 0000 dmesg |grep PCI reports ... PCI: PCI BIOS revision 2.10 entry at 0xfd880, last bus=7 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7110] at 00:07.0 Limiting direct PCI/PCI transfers. Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled PIIX4: IDE controller on PCI bus 00 dev 39 PCI: Found IRQ 11 for device 00:07.2 PCI: Found IRQ 11 for device 00:02.0 PCI: Sharing IRQ 11 with 00:06.0 PCI: Sharing IRQ 11 with 01:00.0 PCI: Found IRQ 11 for device 00:02.1 Yenta IRQ list 0698, PCI irq11 Yenta IRQ list 0698, PCI irq11 PCI: Enabling device 05:00.0 (0000 -> 0003) The PCI BIOS has not enabled the device at 5/0! Updating PCI command 0003->0007. PCI: Setting latency timer of device 05:00.0 to 64 PCI: Enabling device 05:00.0 (0000 -> 0003) lspci -v reports ... 05:00.0 Ethernet controller: Linksys Fast Ethernet 10/100 (rev 11) Subsystem: Netgear: Unknown device 511a Flags: medium devsel, IRQ 11 I/O ports at 4800 [size=256] Memory at 12c00000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at 12800000 [size=128K] Capabilities: [c0] Power Management version 2 Is there anything else of relevance that I could report on? -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From RWMarch@sympatico.ca Wed Jan 15 07:00:54 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Wed Jan 15 07:00:54 2003 Subject: [tulip] Re: NetGear FA511 PC Card Message-ID: <200301150036.13634.RWMarch@sympatico.ca> Further to my previous post, when I physically remove the card and then re-insert it, /var/log/messges reports ... Jan 15 00:16:56 localhost kernel: cs: cb_alloc(bus 5): vendor 0x1317, device 0x1985 Jan 15 00:16:56 localhost kernel: PCI: Enabling device 05:00.0 (0000 -> 0003) Jan 15 00:16:56 localhost cardmgr[698]: initializing socket 1 Jan 15 00:16:56 localhost cardmgr[698]: unsupported card in socket 1 Jan 15 00:16:56 localhost /etc/hotplug/pci.agent: ... no modules for PCI slot 05:00.0 Jan 15 00:16:56 localhost cardmgr[698]: product info: "N" Jan 15 00:16:56 localhost cardmgr[698]: PCI id: 0x1317, 0x1985 I find that pci-scan and tulip get loaded. Packets are transmitted but none are received. "Trying to free non-existent resource" is also seen in /var/log/messages (see previous post). That sounds ominous. -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From RWMarch@sympatico.ca Wed Jan 15 15:13:01 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Wed Jan 15 15:13:01 2003 Subject: [tulip] Re: [tulip-bug] tulip_cb and Netgear FA511 CardBus error Message-ID: <200301151157.34836.RWMarch@sympatico.ca> On Tue, 14 May 2002, Felix Wong wrote: > I have been trying to get a Netgear FA511 CardBus Ethernet > 10/100 card > to work on an HP Pavilion N3478 Laptop running RedHat 7.3 > without success. > > I downloaded tulip.c, pci-scan.c, pci-scan.h and > kern_comp.h, compiled > and install and get the following error (from dmesg): > > ------------- > Linux Kernel Card Services 3.1.22 > options: [pci] [cardbus] [pm] > PCI: Found IRQ 11 for device 00:0a.0 > Yenta IRQ list 0028, PCI irq11 > Socket status: 30000827 > cs: cb_alloc(bus 2): vendor 0x1317, device 0x1985 > PCI: Failed to allocate resource 0(1000-fff) for 02:00.0 And Donald wrote ... " This is the problem -- it occurs before any card driver is loaded. The 3.1.22 card services is trying to allocate a huge amount of space -- (unsigned)-1. Try updating your PCMCIA code. (Did 3.1.22 really ship with RH7.3?) " Yes. It did. I can confirm this based on my RH7.3 system. Question: Before building and installing the pcmcia-cs-3.2.3.tar.gz package, should the RH rpm be erased? The PCMCIA-HOWTO does not address this question. -Robert -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From RWMarch@sympatico.ca Thu Jan 16 16:25:26 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Thu Jan 16 16:25:26 2003 Subject: [tulip] Not assigned an IRQ for an FA511 Message-ID: <200301161326.17970.RWMarch@sympatico.ca> RH7.3 ships eith PCMCIA based on pcmcia-cs-3.1.22. This code is getting long in the tooth, so I rebuilt kernel without PCMCIA support and installed pcmcia-cs-3.2.3. The PCMCIA subsystem started OK and tulip_cb loaded OK. But, as expected, the card would only slowly transmit and not receive. So, I installed the scyld netdrivers. Made entries in /etc/pcmcia/config for the tulip driver. Once again, the PCMCIA subsystem starts OK ... Module Size Used by Not tainted cs4232 4960 2 (autoclean) ad1848 23552 0 (autoclean) [cs4232] uart401 7776 0 (autoclean) [cs4232] sound 69164 2 [cs4232 ad1848 uart401] abi-sco 13848 0 (unused) abi-cxenix 7680 0 [abi-sco] abi-svr4 77872 0 [abi-sco abi-cxenix] lcall7 2228 0 [abi-sco abi-cxenix] abi-util 1404 0 [lcall7] binfmt_coff 6676 0 mwave 31812 4 apm 12324 2 ds 8352 2 i82365 26416 2 pcmcia_core 43872 0 [ds i82365] mousedev 5024 1 hid 20608 0 (unused) input 5728 0 [mousedev hid] rtc 7612 0 (autoclean) However, tulip does not load. Here is dmesg ... PCI: Found IRQ 11 for device 00:07.2 uhci.c: USB UHCI at I/O 0x8400, IRQ 11 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 32768 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 76k freed hub.c: USB new device connect on bus1/1, assigned device number 2 hub.c: USB hub found hub.c: 4 ports detected hub.c: USB new device connect on bus1/1/4, assigned device number 3 usb.c: USB device 3 (vend/prod 0x45e/0x40) is not claimed by any active driver. Real Time Clock Driver v1.10e usb.c: registered new driver hiddev usb.c: registered new driver hid input0: USB HID v1.00 Mouse [Microsoft Microsoft Wheel Mouse OpticalŽ] on usb1:3 .0 hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik hid-core.c: USB HID support drivers mice: PS/2 mouse device common for all mice Adding Swap: 204080k swap-space (priority -1) EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,5), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. parport0: PC-style at 0x3bc [PCSPP,TRISTATE] pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.co m/linux/drivers.html tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html Linux PCMCIA Card Services 3.2.3 kernel build: 2.4.18-19.7.x-Jan15 #2 Wed Jan 15 22:05:07 EST 2003 options: [pci] [cardbus] [apm] Intel ISA/PCI/CardBus PCIC probe: PCI: Found IRQ 11 for device 00:02.0 PCI: Sharing IRQ 11 with 00:06.0 PCI: Sharing IRQ 11 with 01:00.0 PCI: Found IRQ 11 for device 00:02.1 TI 1251A rev 00 PCI-to-CardBus at slot 00:02, mem 0x50102000 host opts [0]: [ring] [isa irq] [pci irq 11] [lat 168/176] [bus 2/4] host opts [1]: [ring] [isa irq] [pci irq 11] [lat 168/176] [bus 5/7] ISA irqs (scanned) = 3,4,7,10 PCI status changes cs: cb_alloc(bus 2): vendor 0x1317, device 0x1985 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) ttyS1 at port 0x02f8 (irq = 3) is a 16550A pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.co m/linux/drivers.html tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html PCI device 'ADMtek Centaur-C' was not assigned an IRQ. It will not be activated. pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.co m/linux/drivers.html tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html PCI device 'ADMtek Centaur-C' was not assigned an IRQ. It will not be activated. And lspci -v -n gives ... pcilib: Cannot open /proc/bus/pci/02/00.0 lspci: Unable to read 64 bytes of configuration space. Any help appreciated. -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From gregt@maths.otago.ac.nz Thu Jan 16 19:06:01 2003 From: gregt@maths.otago.ac.nz (Greg Trounson) Date: Thu Jan 16 19:06:01 2003 Subject: [tulip] End of the free PCI vendor/device list Message-ID: <3E2748BC.3090208@maths.otago.ac.nz> A rather worrying article at slashdot this morning: http://slashdot.org/article.pl?sid=03/01/16/180209 Do the tulip developers use this resource? Greg From becker@scyld.com Thu Jan 16 23:34:02 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 16 23:34:02 2003 Subject: [tulip] End of the free PCI vendor/device list In-Reply-To: <3E2748BC.3090208@maths.otago.ac.nz> Message-ID: On Fri, 17 Jan 2003, Greg Trounson wrote: > From: Greg Trounson > To: tulip@scyld.com > Subject: [tulip] End of the free PCI vendor/device list > > A rather worrying article at slashdot this morning: > http://slashdot.org/article.pl?sid=03/01/16/180209 My reading of this story is that web page used the PCI logo, not just word "PCI". This use of the trademark allowed the notice letter to "carry along" the otherwise allowable use of "PCI". > Do the tulip developers use this resource? This is situation unfortunate, but the list had many inaccurate or just-plain-wrong entries. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From john@deater.net Thu Jan 23 05:48:01 2003 From: john@deater.net (John Clemens) Date: Thu Jan 23 05:48:01 2003 Subject: [tulip] Faster hd --> Centaur-P transmit freeze? Message-ID: I recently replaced an old 5400 RPM drive that failed with a nice new fast 40GB 7200 rpm one in my NFS server. I had been running 2.4.16 w/ stock tulip driver for over a year no problems. Now, under heavy transmit load (reading a large file off the new drive off of NFS) I get what appear to be transmit lockups. I've tried 2.4.16, 2.4.18, 2.4.20 stock kernel drivers, and then the tried and true Becker ones... still no joy. Symptoms include little or no messages on the console, but no traffic gets into or out of the box. A rmmod/insmod doesn't help, only a reboot. Under light load it works fine. System is now 2.4.20. The only messages on the console from the Becker drivers are the occasional "too much work in interrupt" message. lots of times i don't get anything, just no networking. The other ones complained of transmit timeouts. Unmasking the interrupts from the IDE drives seems to help, and just to be certain I've forced the card to use MII 100baseTx-HD (its on a hub with various other network cards..collisions are high, as usual). info and tulip-diag output from idle and stuck conditions included. Notice it's stuck in "waiting for transmit to finish" state..Hmm...more info upon request. Any help would be appreciated..thanks john.c tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: ADMtek Centaur-P rev 17 at 0xd88a3000, 00:20:78:10:98:11, IRQ 11. eth0: Transceiver selection forced to MII 100baseTx. eth0: MII transceiver #1 config 3000 status 786d advertising 01e1. eth0: Advertising 0080 on PHY 1, previously advertising 01e1. tulip-diang -f -aa -mm -ee (idle): tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-P adapter at 0x2800. ADMtek AL985 Centaur-P chip registers at 0x2800: 0x00: fff98000 ffffffff ffffffff 1745a000 1745a200 fc664010 ff972117 ffffebff 0x40: fffe0000 fff597f8 00000000 fffe0000 00000000 00000200 00000000 c40ffec8 Extended registers: 0x80: 00664010 03fe6bff 804c0005 ffffffff 00000000 1745a260 1745a110 ffe0f000 0xa0: f0000000 10782000 ffff1198 00000000 40000000 00000000 00000000 00000000 0xc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0xe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 a0000027 Comet duplex is reported in the MII status registers. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Comet MAC address registers 10782000 ffff1198 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. Ethernet MAC Station Address 00:20:78:10:98:11. Default connection type 'Autosense'. PCI IDs Vendor 1317 Device 0985 Subsystem 1317 0574 PCI min_grant 255 max_latency 255. CSR18 power-up setting 0x804c****. EEPROM contents (256 words): 0x00: 0985 0002 0000 0000 2000 1078 1198 0000 0x08: 0000 0400 0000 0000 0000 0000 0000 0100 0x10: 0985 1317 0574 1317 ffff 0202 0000 804c 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0040 0040 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 7354 0x40: 0301 396a 17ff 4903 ff00 0420 01bf 2227 0x48: 2315 0104 4341 5443 4e4f 4500 324e 3232 0x50: 2d37 4350 434d 4149 4500 324e 3232 0037 0x58: 3052 0031 1aff 0105 f827 0303 141b c1e0 0x60: 3f7d 4d55 065d 46b6 fc46 4524 ff30 28ff 0x68: 0032 071b 0820 60ca 0300 1b1f 2107 ca08 0x70: 2060 1f03 071b 0822 60ca 0340 1b1f 2307 0x78: ca08 6060 1f03 0014 0221 0006 ffff ffff 0x80: 0301 396a 17ff 4903 ff00 0420 01bf 2227 0x88: 2315 0104 4341 5443 4e4f 4500 324e 3232 0x90: 2d37 4350 434d 4149 4500 324e 3232 0037 0x98: 3052 0031 1aff 0105 f827 0303 141b c1e0 0xa0: 0301 396a 17ff 4903 ff00 0420 01bf 2227 0xa8: 2315 0104 4341 5443 4e4f 4500 324e 3232 0xb0: 2d37 4350 434d 4149 4500 324e 3232 0037 0xb8: 3052 0031 1aff 0105 f827 0303 141b c1e0 0xc0: 3f7d 4d55 065d 46b6 fc46 4524 ff30 28ff 0xc8: 0032 071b 0820 60ca 0300 1b1f 2107 ca08 0xd0: 2060 1f03 071b 0822 60ca 0340 1b1f 2307 0xd8: ca08 6060 1f03 0014 0221 0006 ffff ffff 0xe0: 0000 0000 0000 0000 0000 0000 0000 0000 0xe8: 0000 0000 0000 0000 0000 0000 0000 0000 0xf0: 0000 0000 0000 0000 0000 0000 0000 0000 0xf8: 0000 0000 0000 0000 0000 0000 0000 0000 ID block CRC 0xa8 (vs. 00). Full contents CRC 0x7354 (read as 0x7354). MII PHY found at address 1, status 0x786d. MII PHY found at address 2, status 0x786d. MII PHY found at address 3, status 0x786d. MII PHY found at address 4, status 0x786d. MII PHY #1 transceiver registers: 1000 786d 0022 5410 01e1 0081 0004 2001 ffff ffff ffff ffff ffff ffff ffff ffff 01c0 0040 0499 8020 4f02 0304 0026 0000 e60b cfbf 0000 ffff ffff ffff ffff ffff. MII PHY #2 transceiver registers: ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. MII PHY #3 transceiver registers: ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. MII PHY #4 transceiver registers: ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. ./tulip-diag -f -ee -mm -aa (stuck): tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-P adapter at 0x2800. ADMtek AL985 Centaur-P chip registers at 0x2800: 0x00: fff98000 ffffffff ffffffff 1745a000 1745a200 fc264010 ffbfe117 ffffebff 0x40: fffe0000 fff597f8 00000000 fffe0000 00000000 00000200 00000000 c40ffec8 Extended registers: 0x80: 00264010 03fe6bff 804c0004 0000ff00 00000000 1745a2f0 1745a160 ffe0f000 0xa0: f0000000 10782000 ffff1198 00000000 40000000 00000000 00000000 00000000 0xc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0xe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 a0000027 Comet duplex is reported in the MII status registers. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit unit is set to store-and-forward. Comet MAC address registers 10782000 ffff1198 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. Ethernet MAC Station Address 00:20:78:10:98:11. Default connection type 'Autosense'. PCI IDs Vendor 1317 Device 0985 Subsystem 1317 0574 PCI min_grant 255 max_latency 255. CSR18 power-up setting 0x804c****. EEPROM contents (256 words): 0x00: 0985 0002 0000 0000 2000 1078 1198 0000 0x08: 0000 0400 0000 0000 0000 0000 0000 0100 0x10: 0985 1317 0574 1317 ffff 0202 0000 804c 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0040 0040 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 7354 0x40: 0301 396a 17ff 4903 ff00 0420 01bf 2227 0x48: 2315 0104 4341 5443 4e4f 4500 324e 3232 0x50: 2d37 4350 434d 4149 4500 324e 3232 0037 0x58: 3052 0031 1aff 0105 f827 0303 141b c1e0 0x60: 3f7d 4d55 065d 46b6 fc46 4524 ff30 28ff 0x68: 0032 071b 0820 60ca 0300 1b1f 2107 ca08 0x70: 2060 1f03 071b 0822 60ca 0340 1b1f 2307 0x78: ca08 6060 1f03 0014 0221 0006 ffff ffff 0x80: 0301 396a 17ff 4903 ff00 0420 01bf 2227 0x88: 2315 0104 4341 5443 4e4f 4500 324e 3232 0x90: 2d37 4350 434d 4149 4500 324e 3232 0037 0x98: 3052 0031 1aff 0105 f827 0303 141b c1e0 0xa0: 0301 396a 17ff 4903 ff00 0420 01bf 2227 0xa8: 2315 0104 4341 5443 4e4f 4500 324e 3232 0xb0: 2d37 4350 434d 4149 4500 324e 3232 0037 0xb8: 3052 0031 1aff 0105 f827 0303 141b c1e0 0xc0: 3f7d 4d55 065d 46b6 fc46 4524 ff30 28ff 0xc8: 0032 071b 0820 60ca 0300 1b1f 2107 ca08 0xd0: 2060 1f03 071b 0822 60ca 0340 1b1f 2307 0xd8: ca08 6060 1f03 0014 0221 0006 ffff ffff 0xe0: 0000 0000 0000 0000 0000 0000 0000 0000 0xe8: 0000 0000 0000 0000 0000 0000 0000 0000 0xf0: 0000 0000 0000 0000 0000 0000 0000 0000 0xf8: 0000 0000 0000 0000 0000 0000 0000 0000 ID block CRC 0xa8 (vs. 00). Full contents CRC 0x7354 (read as 0x7354). MII PHY found at address 1, status 0x784d. MII PHY found at address 2, status 0x784d. MII PHY found at address 3, status 0x784d. MII PHY found at address 4, status 0x784d. MII PHY #1 transceiver registers: 2000 784d 0022 5410 0081 0081 0004 2001 ffff ffff ffff ffff ffff ffff ffff ffff 01c0 0000 0600 8020 4f02 0304 0026 0000 f91f cfbf 0000 ffff ffff ffff ffff ffff. MII PHY #2 transceiver registers: ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. MII PHY #3 transceiver registers: ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. MII PHY #4 transceiver registers: ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. From profmakx@profmakx.org Sat Jan 25 09:47:06 2003 From: profmakx@profmakx.org (Markus Pfeiffer) Date: Sat Jan 25 09:47:06 2003 Subject: [tulip] Fwd: Cogent/Adaptec ANA 6144 Problem Message-ID: <200301241459.56656.profmakx@profmakx.org> Hello First off, please cc all answers to me as i'm not subscribed to the tulip list. I have an odd problem here with tulip drivers (kernel 2.4.20 as well as drivers from scyld.com, I hope Jeff is reading here too, if not I'll contact him as well). I have a server (Tualatin PIII, MSI Board) with Debian woody and debian kernel 2.4.20-686(-smp) and a an Cogent/Adaptec ANA 6144 board (4 Ports). When I plug my aDSL modem into the one Port and my internal net into the other this results in strange behaviour of the network. (When I connect using 2 RTL8139 everything works fine, so I think I can rule out other network/hardware problems). For example when I run "apt-get upgrade" the file transfer starts out pretty fast and at a certain point, it stops and I get "data socked timed out" error. Funny thing is: For example when installing libncurses5-dev it stops at 41% (deterministic :)). When I try to mount nfs-shares I sometimes get "RPC unable to receive". I tried: driver from debian linux 2.4.20-686 (-smp) driver from scyld.com with and without noapic Finally I'm at a loss :) what else can I try? I appended tulip-diag -aa -ee output at the end of the mail. Cheers Markus -- tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xa000. Port selection is MII, full-duplex. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1109, device 2400. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:92:A7:8E:B8. This table is for a multiport card with 4 controllers. EEPROM transceiver/media description table. Leaf node at offset 40, default media type 0800 (Autosense). CSR12 direction setting bits 0x3f. 1 transceiver description blocks: Media MII, block type 1, length 14. MII interface PHY 0 (media type 11). No MII reset sequence.. 21140 MII initialization sequence is 2 words: 01 00. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. The Magic Packet address is 00:00:00:00:00:00. EEPROM contents (64 words): 0x00: 1109 2400 0000 0000 0000 0000 0000 0000 0x08: 0005 0403 0000 a792 b88e 2804 0500 0028 0x10: 2806 0700 0028 0000 0800 013f 018e 0200 0x18: 0001 0000 e078 0001 0050 0018 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0324 d7a2 ID block CRC 0x05 (vs. 0x05). Full contents CRC 0xd7a2 (read as 0xd7a2). MII PHY found at address 1, status 0x786f. MII PHY #1 transceiver registers: 3100 786f 2000 5c01 01e1 41e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0ca1 0000 1800 a3b9 007d 2305 001b. Index #2: Found a Digital DS21140 Tulip adapter at 0xa400. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 256 words, 8 address bits. WARNING: The EEPROM is missing or erased! This interface is missing the EEPROM. This is likely the non-primary interface on a multiport board. EEPROM contents (256 words): 0x00: ffff ffff ffff ffff ffff ffff ffff ffff 0x08: ffff ffff ffff ffff ffff ffff ffff ffff 0x10: ffff ffff ffff ffff ffff ffff ffff ffff 0x18: ffff ffff ffff ffff ffff ffff ffff ffff 0x20: ffff ffff ffff ffff ffff ffff ffff ffff 0x28: ffff ffff ffff ffff ffff ffff ffff ffff 0x30: ffff ffff ffff ffff ffff ffff ffff ffff 0x38: ffff ffff ffff ffff ffff ffff ffff ffff 0x40: ffff ffff ffff ffff ffff ffff ffff ffff 0x48: ffff ffff ffff ffff ffff ffff ffff ffff 0x50: ffff ffff ffff ffff ffff ffff ffff ffff 0x58: ffff ffff ffff ffff ffff ffff ffff ffff 0x60: ffff ffff ffff ffff ffff ffff ffff ffff 0x68: ffff ffff ffff ffff ffff ffff ffff ffff 0x70: ffff ffff ffff ffff ffff ffff ffff ffff 0x78: ffff ffff ffff ffff ffff ffff ffff ffff 0x80: ffff ffff ffff ffff ffff ffff ffff ffff 0x88: ffff ffff ffff ffff ffff ffff ffff ffff 0x90: ffff ffff ffff ffff ffff ffff ffff ffff 0x98: ffff ffff ffff ffff ffff ffff ffff ffff 0xa0: ffff ffff ffff ffff ffff ffff ffff ffff 0xa8: ffff ffff ffff ffff ffff ffff ffff ffff 0xb0: ffff ffff ffff ffff ffff ffff ffff ffff 0xb8: ffff ffff ffff ffff ffff ffff ffff ffff 0xc0: ffff ffff ffff ffff ffff ffff ffff ffff 0xc8: ffff ffff ffff ffff ffff ffff ffff ffff 0xd0: ffff ffff ffff ffff ffff ffff ffff ffff 0xd8: ffff ffff ffff ffff ffff ffff ffff ffff 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff 0xf8: ffff ffff ffff ffff ffff ffff ffff ffff ID block CRC 0xfa (vs. 0xff). Full contents CRC 0x6a15 (read as 0xffff). MII PHY found at address 1, status 0x7849. MII PHY #1 transceiver registers: 1000 7849 2000 5c01 01e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c61 0000 3800 a3b9 0080 8005 001b. Index #3: Found a Digital DS21140 Tulip adapter at 0xa800. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 256 words, 8 address bits. WARNING: The EEPROM is missing or erased! This interface is missing the EEPROM. This is likely the non-primary interface on a multiport board. EEPROM contents (256 words): 0x00: ffff ffff ffff ffff ffff ffff ffff ffff 0x08: ffff ffff ffff ffff ffff ffff ffff ffff 0x10: ffff ffff ffff ffff ffff ffff ffff ffff 0x18: ffff ffff ffff ffff ffff ffff ffff ffff 0x20: ffff ffff ffff ffff ffff ffff ffff ffff 0x28: ffff ffff ffff ffff ffff ffff ffff ffff 0x30: ffff ffff ffff ffff ffff ffff ffff ffff 0x38: ffff ffff ffff ffff ffff ffff ffff ffff 0x40: ffff ffff ffff ffff ffff ffff ffff ffff 0x48: ffff ffff ffff ffff ffff ffff ffff ffff 0x50: ffff ffff ffff ffff ffff ffff ffff ffff 0x58: ffff ffff ffff ffff ffff ffff ffff ffff 0x60: ffff ffff ffff ffff ffff ffff ffff ffff 0x68: ffff ffff ffff ffff ffff ffff ffff ffff 0x70: ffff ffff ffff ffff ffff ffff ffff ffff 0x78: ffff ffff ffff ffff ffff ffff ffff ffff 0x80: ffff ffff ffff ffff ffff ffff ffff ffff 0x88: ffff ffff ffff ffff ffff ffff ffff ffff 0x90: ffff ffff ffff ffff ffff ffff ffff ffff 0x98: ffff ffff ffff ffff ffff ffff ffff ffff 0xa0: ffff ffff ffff ffff ffff ffff ffff ffff 0xa8: ffff ffff ffff ffff ffff ffff ffff ffff 0xb0: ffff ffff ffff ffff ffff ffff ffff ffff 0xb8: ffff ffff ffff ffff ffff ffff ffff ffff 0xc0: ffff ffff ffff ffff ffff ffff ffff ffff 0xc8: ffff ffff ffff ffff ffff ffff ffff ffff 0xd0: ffff ffff ffff ffff ffff ffff ffff ffff 0xd8: ffff ffff ffff ffff ffff ffff ffff ffff 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff 0xf8: ffff ffff ffff ffff ffff ffff ffff ffff ID block CRC 0xfa (vs. 0xff). Full contents CRC 0x6a15 (read as 0xffff). MII PHY found at address 1, status 0x7849. MII PHY #1 transceiver registers: 1000 7849 2000 5c01 01e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c61 0000 3800 a3b9 0080 8005 001b. Index #4: Found a Digital DS21140 Tulip adapter at 0xac00. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 256 words, 8 address bits. WARNING: The EEPROM is missing or erased! This interface is missing the EEPROM. This is likely the non-primary interface on a multiport board. EEPROM contents (256 words): 0x00: ffff ffff ffff ffff ffff ffff ffff ffff 0x08: ffff ffff ffff ffff ffff ffff ffff ffff 0x10: ffff ffff ffff ffff ffff ffff ffff ffff 0x18: ffff ffff ffff ffff ffff ffff ffff ffff 0x20: ffff ffff ffff ffff ffff ffff ffff ffff 0x28: ffff ffff ffff ffff ffff ffff ffff ffff 0x30: ffff ffff ffff ffff ffff ffff ffff ffff 0x38: ffff ffff ffff ffff ffff ffff ffff ffff 0x40: ffff ffff ffff ffff ffff ffff ffff ffff 0x48: ffff ffff ffff ffff ffff ffff ffff ffff 0x50: ffff ffff ffff ffff ffff ffff ffff ffff 0x58: ffff ffff ffff ffff ffff ffff ffff ffff 0x60: ffff ffff ffff ffff ffff ffff ffff ffff 0x68: ffff ffff ffff ffff ffff ffff ffff ffff 0x70: ffff ffff ffff ffff ffff ffff ffff ffff 0x78: ffff ffff ffff ffff ffff ffff ffff ffff 0x80: ffff ffff ffff ffff ffff ffff ffff ffff 0x88: ffff ffff ffff ffff ffff ffff ffff ffff 0x90: ffff ffff ffff ffff ffff ffff ffff ffff 0x98: ffff ffff ffff ffff ffff ffff ffff ffff 0xa0: ffff ffff ffff ffff ffff ffff ffff ffff 0xa8: ffff ffff ffff ffff ffff ffff ffff ffff 0xb0: ffff ffff ffff ffff ffff ffff ffff ffff 0xb8: ffff ffff ffff ffff ffff ffff ffff ffff 0xc0: ffff ffff ffff ffff ffff ffff ffff ffff 0xc8: ffff ffff ffff ffff ffff ffff ffff ffff 0xd0: ffff ffff ffff ffff ffff ffff ffff ffff 0xd8: ffff ffff ffff ffff ffff ffff ffff ffff 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff 0xf8: ffff ffff ffff ffff ffff ffff ffff ffff ID block CRC 0xfa (vs. 0xff). Full contents CRC 0x6a15 (read as 0xffff). MII PHY found at address 1, status 0x7849. MII PHY #1 transceiver registers: 1000 7849 2000 5c01 01e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c61 0000 3800 a3b9 0080 8005 001b. ------------------------------------------------------- -- We have no scorched earth policy. We have a policy of scorched Communists. -- General Efrain Rios Montt, President of Guatemala, 1982 From becker@scyld.com Sat Jan 25 10:28:01 2003 From: becker@scyld.com (Donald Becker) Date: Sat Jan 25 10:28:01 2003 Subject: [tulip] Fwd: Cogent/Adaptec ANA 6144 Problem In-Reply-To: <200301241459.56656.profmakx@profmakx.org> Message-ID: On Fri, 24 Jan 2003, Markus Pfeiffer wrote: > I have a server (Tualatin PIII, MSI Board) with Debian woody and debian > kernel 2.4.20-686(-smp) and a an Cogent/Adaptec ANA 6144 board (4 Ports). > When I plug my aDSL modem into the one Port and my internal net into the > other this results in strange behaviour of the network. (When I connect > using 2 RTL8139 everything works fine, so I think I can rule out other > network/hardware problems). > > For example when I run "apt-get upgrade" the file transfer starts out pretty > fast and at a certain point, it stops and I get "data socked timed out" > error. Funny thing is: For example when installing libncurses5-dev it stops > at 41% (deterministic :)). What driver version are you using? What is the detection message? What error messages are you seeing from the driver? What are the error counts in /proc/net/dev? > I appended tulip-diag -aa -ee output at the end of the mail. What is the diagnostic report when the transfer slows? > Index #1: Found a Digital DS21140 Tulip adapter at 0xa000. > Port selection is MII, full-duplex. > Transmit started, Receive started. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 128. This is a normal, working state for a 21140. > MII PHY #1 transceiver registers: > 3100 786f 2000 5c01 01e1 41e1 0001 0000 You are connected to a 10/100 switch without flow control. > Index #2: Found a Digital DS21140 Tulip adapter at 0xa400. > MII PHY #1 transceiver registers: > Index #4: Found a Digital DS21140 Tulip adapter at 0xac00. > MII PHY #1 transceiver registers: What happened to Index #3? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rigodcx@yahoo.com Tue Jan 28 10:31:02 2003 From: rigodcx@yahoo.com (Rigoberto de la Cruz) Date: Tue Jan 28 10:31:02 2003 Subject: [tulip] tulip drivers and RH8 Message-ID: <20030128003418.39835.qmail@web21205.mail.yahoo.com> I have RH8 running in my laptop. The laptop has a ethernet/modem combo... I already have the modem up and running, but I'm having difficulties with the tulip drivers. I tried to install the individual driver doing the following (taken from http://www.scyld.com/network/updates.html) : * Copy the driver source files to a convenient directory. I usually use /usr/src/modules/. * Compile both the driver file and pci-scan.c using the compile-command at the bottom of the source files. If a compile-command is not there use the following compile command: gcc -DMODULE -D__KERNEL__ -O6 -c driver.c gcc -DMODULE -D__KERNEL__ -O6 -c pci-scan.c With some distributions, especially those based on the 2.4 kernel, you may need to add the following options to the compile command -I/usr/src/linux/include -include /usr/src/linux/include/linux/modversions.h * As 'root', test the module by doing insmod pci-scan.o insmod driver.o ---------------------------------------- Up to here, everything is going perfeclty.. I can do insmod to both drivers, but then the following step is where I do not know where to copy the drivers. * Install the modules in the proper location for your distribution. This is usually /lib/modules/kernel-version/net/driver.o. The command to do this is install -m 644 pci-scan.o driver.o /lib/modules/2.2.19-13.beo/net/ Can anyone help me? then my next question would be.. how to configure the device.. shuld I use kudzu (sp?) or sould I do it manually? any help would be apreciated.. thanks in advance, Rigo PS. I hope this is the right list... if not, please let me know... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From rowejames@acmsystems.com Wed Jan 29 17:46:01 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Wed Jan 29 17:46:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? Message-ID: <1043881740.7282.20.camel@kneedragger> Hello, I'm using a Netgear FA511 CardBus PC Card with a Ricoh RL5c476 PCI to Cardbus bridge on a PPC platform. The MAC address of my card is 00:10:7A:69:F0:79, however ifconfig and /var/log/messages report it to be 69:7A:10:00:79:F0. Has anyone else run into this problem? I'm using the tulip.o driver from the 2.4.19 kernel, along with the kernel based card services. Here is my /var/log/messages: Nov 30 00:28:40 eth0 kernel: Linux Kernel Card Services 3.1.22 Nov 30 00:28:40 eth0 kernel: options: [pci] [cardbus] Nov 30 00:28:44 eth0 kernel: Yenta IRQ list 0000, PCI irq30 Nov 30 00:28:44 eth0 kernel: Socket status: 30000006 Nov 30 00:28:44 eth0 kernel: Yenta IRQ list 0000, PCI irq30 Nov 30 00:28:44 eth0 kernel: Socket status: 30000820 Nov 30 00:28:49 eth0 kernel: cs: cb_alloc(bus 2): vendor 0x1317, device 0x1985 Nov 30 00:28:49 eth0 kernel: PCI: moved device 02:00.0 resource 0 (101) to 8000 Nov 30 00:28:49 eth0 kernel: PCI: moved device 02:00.0 resource 1 (200) to 80400000 Nov 30 00:28:49 eth0 kernel: PCI: moved device 02:00.0 resource 6 (7201) to bf800000 Nov 30 00:28:49 eth0 kernel: PCI: Enabling device 02:00.0 (0000 -> 0003) Nov 30 00:28:56 eth0 kernel: Linux Tulip driver version 0.9.15-pre11 (May 11, 2002) Nov 30 00:28:56 eth0 kernel: eth1: ADMtek Comet rev 17 at 0x8000, 69:7A:10:00:79:F0, IRQ 30 My lspci -v: root@eth0:/usr/src/linux/drivers/net/tulip# lspci -v 00:07.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) Flags: bus master, medium devsel, latency 168, IRQ 30 Memory at bfff6000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=01, subordinate=01, sec-latency=176 Memory window 0: bfbf6000-bfff5000 (prefetchable) Memory window 1: 80000000-803ff000 I/O window 0: 0000bfd0-0000ffcf I/O window 1: 00004000-000040ff 16-bit legacy interface ports at 0001 00:07.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) Flags: bus master, medium devsel, latency 168, IRQ 30 Memory at bfbf5000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=02, sec-latency=176 Memory window 0: bf7f5000-bfbf4000 (prefetchable) Memory window 1: 80400000-807ff000 I/O window 0: 00007fd0-0000bfcf I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 02:00.0 Ethernet controller: Bridgecom, Inc: Unknown device 1985 (rev 11) Subsystem: Netgear: Unknown device 511a Flags: bus master, medium devsel, latency 0, IRQ 30 I/O ports at 8000 [size=256] Memory at 80400000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at bf800000 [size=128K] Capabilities: [c0] Power Management version 2 lsmod: root@eth0:/usr/src/linux/drivers/net/tulip# lsmod Module Size Used by tulip 44000 0 ds 8688 0 yenta_socket 11792 2 pcmcia_core 42656 0 [ds yenta_socket] root@eth0:/usr/src/linux/drivers/net/tulip# cat /proc/iomem 80000000-bfffffff : PCI Memory 80000000-803fffff : PCI CardBus #01 80400000-807fffff : PCI CardBus #02 80400000-804003ff : PCI device 1317:1985 80400000-804003ff : tulip bf7f5000-bfbf4fff : PCI CardBus #02 bf800000-bf81ffff : PCI device 1317:1985 bfbf5000-bfbf5fff : Ricoh Co Ltd RL5c476 II (#2) bfbf6000-bfff5fff : PCI CardBus #01 bfff6000-bfff6fff : Ricoh Co Ltd RL5c476 II bfff7f00-bfff7fff : CMD Technology Inc PCI0680 bfff8000-bfffbfff : Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) bffff800-bfffffff : Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) My ifconfig -a: root@eth0:/usr/src/linux/drivers/net/tulip# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:04:AC:E3:15:D6 inet addr:172.16.200.34 Bcast:172.16.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:18811 errors:0 dropped:0 overruns:0 frame:0 TX packets:11680 errors:0 dropped:0 overruns:0 carrier:0 collisions:6 txqueuelen:100 Interrupt:15 eth1 Link encap:Ethernet HWaddr 69:7A:10:00:79:F0 inet addr:10.12.11.105 Bcast:10.255.255.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:30 Base address:0x8000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:66 errors:0 dropped:0 overruns:0 frame:0 TX packets:66 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 Thanks for any help, Jim -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From becker@scyld.com Wed Jan 29 19:57:02 2003 From: becker@scyld.com (Donald Becker) Date: Wed Jan 29 19:57:02 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1043881740.7282.20.camel@kneedragger> Message-ID: On 29 Jan 2003, Jim Rowe wrote: > I'm using a Netgear FA511 CardBus PC Card with a Ricoh RL5c476 PCI to > Cardbus bridge on a PPC platform. > > The MAC address of my card is 00:10:7A:69:F0:79, however ifconfig and > /var/log/messages report it to be 69:7A:10:00:79:F0. Has anyone else run > into this problem? > I'm using the tulip.o driver from the 2.4.19 kernel, along with the > kernel based card services. The driver must endian-correct for station address. The driver in the kernel did not copy the code from my driver correctly, resulting in this bug. The driver from Scyld _does_ work correctly. > Nov 30 00:28:56 eth0 kernel: Linux Tulip driver version 0.9.15-pre11 > (May 11, 2002) > Nov 30 00:28:56 eth0 kernel: eth1: ADMtek Comet rev 17 at 0x8000, > 69:7A:10:00:79:F0, IRQ 30 -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From dishrag-invites@starchefs.email-publisher.com Thu Jan 30 13:11:01 2003 From: dishrag-invites@starchefs.email-publisher.com (newsletter@starchefs.com) Date: Thu Jan 30 13:11:01 2003 Subject: [tulip] StarChefs Invitation Message-ID: <1750926482-1463792638-1043949696@topica.com> Dear Valued Reader, Get more flavor from your email every month! StarChefs invites you to receive our free monthly food e-zine, the Dishrag. It's informative, inspiring, -- and FREE! With each issue, you'll receive a recipe, event listings, chef profiles, and food features -- all delivered directly to your Inbox. To subscribe, simply click here http://click.email-publisher.com/maaaOf8aaVG4Xbc4CPsb/ Then, just read and enjoy! There's no risk or obligation - you can unsubscribe at anytime. Below, we have included our Valentine's edition as a sample. ----------------------------------------- If you do not respond to this invitation within 14 days, you will no longer receive any informational emails from StarChefs. We will remove you from our mailing list. ----------------------------------------- >>The Dishrag<< StarChefs Newsletter January 30, 2003 - Issue 49 IN THIS ISSUE 1. Love Lures: Luscious Valentine's Recipes 2. Love Potions No. 4: Drink Ideas to Bewitch Your Lover 3. Chef Michael Schlow 4. Sweet Spot: Pastry Chef Jean-Francois Bonnet 5. StarChefs Culinary JobFinder's Top Five Jobs 6. StarChefs Did You Know? 7. Signature Wine Clubs 8. A Romantic Breakfast Treat ............................................................................... 1. Love Lures: Luscious Valentine's Recipes Fuel your love's passion with these aphrodisiac recipes from seven hot Miami chefs. http://click.email-publisher.com/maaaOf8aaVG4Ybc4CPsb/ ............................................................................... 2. Love Potions No. 4: Drink Ideas to Bewitch Your Lover Liberate your inner Cupid or Aphrodite with these tempting cocktails. http://click.email-publisher.com/maaaOf8aaVG4Zbc4CPsb/ ............................................................................... 3. Chef Michael Schlow New York flair and New England ingredients are his equation for success. StarChefs introduces Michael Schlow of Café Louis, Radius, and Via Matta in Boston. http://click.email-publisher.com/maaaOf8aaVG41bc4CPsb/ ............................................................................... 4. Sweet Spot: Pastry Chef Jean-Francois Bonnet StarChefs' January featured Pastry Chef, Jean-Francois Bonnet of Atelier in New York, brings artistry and flavor to ice-cream sandwiches. It's ok for adults to indulge with this school-lunch favorite. http://click.email-publisher.com/maaaOf8aaVG42bc4CPsb/ ............................................................................... 5. StarChefs Culinary JobFinder's Top Five Jobs A world of creativity awaits you. Grand Florida hotel seeks Pastry Cooks. http://click.email-publisher.com/maaaOf8aaVG43bc4CPsb/ Conduct our house. Forthcoming NYC Asian looking for Dining Room Manager. http://click.email-publisher.com/maaaOf8aaVG44bc4CPsb/ Our bay is your oyster. Cape Cod seafood restaurant looking for summer Line Cooks. http://click.email-publisher.com/maaaOf8aaVG45bc4CPsb/ Our city provides daily adventures. Universal Citywalk seeks experienced Assistant Unit Manager. http://click.email-publisher.com/maaaOf8aaVG46bc4CPsb/ Live in paradise, bake up a storm. Club Med resort needs talented Baker. http://click.email-publisher.com/maaaOf8aaVG47bc4CPsb/ ............................................................................... 6. StarChefs Did You Know? Sun, fun, wine and food await you at the second annual South Beach Wine & Food Festival which takes place in the heart of Miami's South Beach Friday, February 28, through Sunday, March 2, 2003. Surprise your Valentine with this spectacular treat! http://click.email-publisher.com/maaaOf8aaVG48bc4CPsb/ ............................................................................... 7. Signature Wine Clubs Join StarChefs Signature Wine Clubs and each month get two hand-selected "mystery" wines from anywhere in the world. Each featured wine selection comes with an informative dossier and recipe suggestions from celebrity chefs. Now, you can explore the global flavors of wine without leaving home. http://click.email-publisher.com/maaaOf8aaVG7ybc4CPsb/ ............................................................................... 8. A Romantic Breakfast Treat Wake your partner with the seductive scent of this simple recipe. Ricotta-Cottage Cheese Pancakes >From Breakfast in Bed by Jesse Ziff Cool, HarperCollins, 1997 Adapted by StarChefs Yield: 2-4 servings Ingredients: 1 cup unbleached white flour 1 Tablespoon sugar 1/2 teaspoon salt 1 teaspoon baking powder 4 eggs 1 cup ricotta cheese 1 cup small curd cottage cheese 3/4 cup milk 1 teaspoon vanilla extract Vegetable oil To prepare pancakes: In a medium bowl, combine the flour, sugar, salt, and baking powder. In another bowl, beat the eggs with the ricotta, cottage cheese, milk, and vanilla. Gradually add the wet ingredients to the dry, stirring just until blended. Do not overmix. Heat a griddle or heavy skillet over medium heat, and lightly grease it with vegetable oil. Preheat the oven to 250 degrees. Drop the batter onto the hot pan by heaping Tablespoonfuls. When the pancakes are bubbly on top and nicely browned on the bottom, flip them. As they cook through, transfer them to a baking sheet and keep them warm in the oven while you cook the rest of the batter. Serving suggestions: Top pancakes with fresh fruit, dried fruit, or fruit compote. ............................................................... You are receiving this newsletter because you requested it. To e-mail this to a friend, click on the link below (or cut and paste into a browser): mailto:?subject="A great newsletter from StarChefs&body=Check out http://click.email-publisher.com/maaaOf8aaVG7zbc4CPsb/" ................................................................. StarChefs... If you like food. A lot. ==================================================================== Update your profile here: http://topica.email-publisher.com/survey/?a84IUC.bc4CPs.dHVsaXBA Unsubscribe here: http://topica.email-publisher.com/survey/?a84IUC.bc4CPs.dHVsaXBA.u Delivered by Topica Email Publisher, http://topica.email-publisher.com/ From becker@scyld.com Thu Jan 30 13:51:02 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 30 13:51:02 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1043956149.14370.32.camel@kneedragger> Message-ID: On 30 Jan 2003, Jim Rowe wrote: > As you suggested I used the tulip driver from Scyld in the > netdrivers-3.3.tgz package and I still get the same byte swapped MAC > address. Rename the old tulip driver, hard-reset the machine, and the Scyld driver will report the correct address. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rowejames@acmsystems.com Thu Jan 30 13:56:02 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Thu Jan 30 13:56:02 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1043956149.14370.32.camel@kneedragger> As you suggested I used the tulip driver from Scyld in the netdrivers-3.3.tgz package and I still get the same byte swapped MAC address. I built the module with: make KERN_INCLUDE=/usr/src/linux/include MODULEDIR=/tmp/pcmcia-test PCMCIA=/usr/src/linux/include/pcmcia Then: cd /lib/modules/2.4.19-rc1-acms1/kernel/drivers/pcmcia/ insmod pcmcia_core.o insmod yenta_socket.o insmod ds.o cd /usr/src/netdrivers-3.3 insmod pci-scan.o insmod tulip.o The first 32-bit word is still byte swapped, however the second now shows zeros instead of the 79:F0 as last time. Again my MAC address should be 00:10:7A:69:F0:79. Here is my log file: Jan 30 10:40:22 eth0 kernel: Linux Kernel Card Services 3.1.22 Jan 30 10:40:22 eth0 kernel: options: [pci] [cardbus] Jan 30 10:40:23 eth0 kernel: Yenta IRQ list 0000, PCI irq30 Jan 30 10:40:23 eth0 kernel: Socket status: 30000006 Jan 30 10:40:23 eth0 kernel: Yenta IRQ list 0000, PCI irq30 Jan 30 10:40:23 eth0 kernel: Socket status: 30000820 Jan 30 10:40:25 eth0 kernel: cs: cb_alloc(bus 2): vendor 0x1317, device 0x1985 Jan 30 10:40:25 eth0 kernel: PCI: moved device 02:00.0 resource 0 (101) to 8000 Jan 30 10:40:25 eth0 kernel: PCI: moved device 02:00.0 resource 1 (200) to 80400000 Jan 30 10:40:25 eth0 kernel: PCI: moved device 02:00.0 resource 6 (7201) to bf800000 Jan 30 10:40:25 eth0 kernel: PCI: Enabling device 02:00.0 (0000 -> 0003) Jan 30 10:40:26 eth0 kernel: pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.com/linux/drivers.html Jan 30 10:40:27 eth0 kernel: tulip.c:v0.95f 11/17/2002 Written by Donald Becker Jan 30 10:40:27 eth0 kernel: http://www.scyld.com/network/tulip.html Jan 30 10:40:27 eth0 kernel: The PCI BIOS has not enabled the device at 2/0! Updating PCI command 0003->0007. Jan 30 10:40:27 eth0 kernel: eth1: ADMtek Centaur-C rev 17 at 0xc902f000, 69:7A:10:00:00:00, IRQ 30. Jan 30 10:40:27 eth0 kernel: eth1: MII transceiver #1 config 1100 status 7849 advertising 05e1. Jan 30 10:40:27 eth0 kernel: PCI latency timer (CFLT) is unreasonably low at 0. Setting to 32 clocks. -- Jim On Wed, 2003-01-29 at 16:58, Donald Becker wrote: > On 29 Jan 2003, Jim Rowe wrote: > > > I'm using a Netgear FA511 CardBus PC Card with a Ricoh RL5c476 PCI to > > Cardbus bridge on a PPC platform. > > > > The MAC address of my card is 00:10:7A:69:F0:79, however ifconfig and > > /var/log/messages report it to be 69:7A:10:00:79:F0. Has anyone else run > > into this problem? > > I'm using the tulip.o driver from the 2.4.19 kernel, along with the > > kernel based card services. > > The driver must endian-correct for station address. > The driver in the kernel did not copy the code from my driver correctly, > resulting in this bug. The driver from Scyld _does_ work correctly. > > > Nov 30 00:28:56 eth0 kernel: Linux Tulip driver version 0.9.15-pre11 > > (May 11, 2002) > > Nov 30 00:28:56 eth0 kernel: eth1: ADMtek Comet rev 17 at 0x8000, > > 69:7A:10:00:79:F0, IRQ 30 -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From becker@scyld.com Thu Jan 30 14:11:00 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 30 14:11:00 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1043957184.14370.37.camel@kneedragger> Message-ID: On 30 Jan 2003, Jim Rowe wrote: > On Thu, 2003-01-30 at 10:51, Donald Becker wrote: > > On 30 Jan 2003, Jim Rowe wrote: > > > As you suggested I used the tulip driver from Scyld in the > > > netdrivers-3.3.tgz package and I still get the same byte swapped MAC > > > address. > > > > Rename the old tulip driver, hard-reset the machine, and the Scyld > > driver will report the correct address. > > I tried this with no success. I'm positive I'm not using the old tulip > driver from the kernel source tree. Any ideas? This is an issue that is unique to the Comet: once the old Tulip driver is run, the address will remain byte-reversed until the chip is completely powered off. The Comet chip is a case where re-loading the driver will not clear the problem. If this is a laptop, you must remove the battery, not just reboot. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rowejames@acmsystems.com Thu Jan 30 14:11:09 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Thu Jan 30 14:11:09 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1043957184.14370.37.camel@kneedragger> On Thu, 2003-01-30 at 10:51, Donald Becker wrote: > On 30 Jan 2003, Jim Rowe wrote: > > As you suggested I used the tulip driver from Scyld in the > > netdrivers-3.3.tgz package and I still get the same byte swapped MAC > > address. > > Rename the old tulip driver, hard-reset the machine, and the Scyld > driver will report the correct address. I tried this with no success. I'm positive I'm not using the old tulip driver from the kernel source tree. Any ideas? -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From becker@scyld.com Thu Jan 30 14:44:01 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 30 14:44:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1043959098.14370.40.camel@kneedragger> Message-ID: On 30 Jan 2003, Jim Rowe wrote: > Excellent! That was the trick. Thanks for your help Donald. OK, just to summarize: There is a bug in the kernel's tulip driver that byte-swaps the station address when used with the Comet chip. The bug may manifest itself as the ability to ping but not communicate with TCP or UDP. The exact symptoms depend on the station address and the local router configuration. The driver from Scyld works correctly, but does require that the interface go through a hard-power-off if the flawed kernel driver is run first. Please confirm that this is the case. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rowejames@acmsystems.com Thu Jan 30 14:46:00 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Thu Jan 30 14:46:00 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1043959098.14370.40.camel@kneedragger> On Thu, 2003-01-30 at 11:11, Donald Becker wrote: > On 30 Jan 2003, Jim Rowe wrote: > > > On Thu, 2003-01-30 at 10:51, Donald Becker wrote: > > > On 30 Jan 2003, Jim Rowe wrote: > > > > As you suggested I used the tulip driver from Scyld in the > > > > netdrivers-3.3.tgz package and I still get the same byte swapped MAC > > > > address. > > > > > > Rename the old tulip driver, hard-reset the machine, and the Scyld > > > driver will report the correct address. > > > > I tried this with no success. I'm positive I'm not using the old tulip > > driver from the kernel source tree. Any ideas? > > This is an issue that is unique to the Comet: once the old Tulip driver > is run, the address will remain byte-reversed until the chip is > completely powered off. The Comet chip is a case where re-loading the > driver will not clear the problem. > > If this is a laptop, you must remove the battery, not just reboot. Excellent! That was the trick. Thanks for your help Donald. -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From rowejames@acmsystems.com Thu Jan 30 15:16:01 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Thu Jan 30 15:16:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1043961253.14370.56.camel@kneedragger> On Thu, 2003-01-30 at 11:44, Donald Becker wrote: > On 30 Jan 2003, Jim Rowe wrote: > > Excellent! That was the trick. Thanks for your help Donald. > > OK, just to summarize: > > There is a bug in the kernel's tulip driver that byte-swaps the > station address when used with the Comet chip. Yes, the tulip driver in kernel 2.4.19 will byte swap the hardware address when running on a CardBus interface on the PPC. It may swap other data, but for sure it swaps the MAC. > > The bug may manifest itself as the ability to ping but not communicate > with TCP or UDP. The exact symptoms depend on the station address and > the local router configuration. I was not able to ping or communicate with TCP or UDP. > > The driver from Scyld works correctly, but does require that the > interface go through a hard-power-off if the flawed kernel driver is > run first. Yes. If the tulip driver in the kernel tree is loaded first power needs to be shut off, and the Scyld driver loaded. The MAC address is then reported correctly. Note I still haven't had any success pinging or communicating with the cardbus interface, however the information that is reported by /var/log/messages and ifconfig now looks correct. Has this driver been known to work correctly with a CardBus interface on the PPC? I'm working with some custom hardware and it would be helpful to know if the driver has been tested on such a setup. Thanks, Jim > Please confirm that this is the case. -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From becker@scyld.com Thu Jan 30 16:15:00 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 30 16:15:00 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1043961253.14370.56.camel@kneedragger> Message-ID: On 30 Jan 2003, Jim Rowe wrote: > > There is a bug in the kernel's tulip driver that byte-swaps the > > station address when used with the Comet chip. > > Yes, the tulip driver in kernel 2.4.19 will byte swap the hardware > address when running on a CardBus interface on the PPC. It may swap > other data, but for sure it swaps the MAC. .. > Note I still haven't had any success pinging or communicating with the > cardbus interface, however the information that is reported by > /var/log/messages and ifconfig now looks correct. > > Has this driver been known to work correctly with a CardBus interface on > the PPC? I'm working with some custom hardware and it would be helpful > to know if the driver has been tested on such a setup. Hmmm, not a CardBus interface. There are additional opportunities for screwing up with CardBus -- usually broken address space configuration. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From becker@scyld.com Thu Jan 30 16:47:01 2003 From: becker@scyld.com (Donald Becker) Date: Thu Jan 30 16:47:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1043966583.14370.72.camel@kneedragger> Message-ID: On 30 Jan 2003, Jim Rowe wrote: > I'm not having any luck. I have my network setup properly and I'm not > able to communicate with any devices on the same subnet. The transmit > and receive statistics given by ifconfig show that nothing is going in > or out of the interface. Do not use the output of 'ifconfig' to diagnose problems. The 'ifconfig' program tries to be compatible with old BSD, which had only rudimentary error counts. You should use the numbers in /proc/net/dev instead. If there is a problem, the driver will emit a message. You should check your kernel message logs. > What type of things should I look for to check for broken address space > configuration? There are far too many possible problems to list. > I'm not required to use a tulip-based card for my project. I'm > considering using a 3c59x-based CardBus PC Card to see if I have any > better luck. Any suggesstions? That will narrow the problem space down. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rowejames@acmsystems.com Thu Jan 30 16:49:01 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Thu Jan 30 16:49:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1043966583.14370.72.camel@kneedragger> On Thu, 2003-01-30 at 13:15, Donald Becker wrote: > On 30 Jan 2003, Jim Rowe wrote: > > > > There is a bug in the kernel's tulip driver that byte-swaps the > > > station address when used with the Comet chip. > > > > Yes, the tulip driver in kernel 2.4.19 will byte swap the hardware > > address when running on a CardBus interface on the PPC. It may swap > > other data, but for sure it swaps the MAC. > .. > > Note I still haven't had any success pinging or communicating with the > > cardbus interface, however the information that is reported by > > /var/log/messages and ifconfig now looks correct. > > > > Has this driver been known to work correctly with a CardBus interface on > > the PPC? I'm working with some custom hardware and it would be helpful > > to know if the driver has been tested on such a setup. > > Hmmm, not a CardBus interface. There are additional opportunities for > screwing up with CardBus -- usually broken address space configuration. I'm not having any luck. I have my network setup properly and I'm not able to communicate with any devices on the same subnet. The transmit and receive statistics given by ifconfig show that nothing is going in or out of the interface. What type of things should I look for to check for broken address space configuration? Here is my /proc/iomem: 80000000-bfffffff : PCI Memory 80000000-803fffff : PCI CardBus #01 80400000-807fffff : PCI CardBus #02 80400000-804003ff : PCI device 1317:1985 bf7f5000-bfbf4fff : PCI CardBus #02 bf800000-bf81ffff : PCI device 1317:1985 bfbf5000-bfbf5fff : Ricoh Co Ltd RL5c476 II (#2) bfbf6000-bfff5fff : PCI CardBus #01 bfff6000-bfff6fff : Ricoh Co Ltd RL5c476 II bfff7f00-bfff7fff : CMD Technology Inc PCI0680 bfff8000-bfffbfff : Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) bffff800-bfffffff : Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) And lspci -v: root@eth0:~# lspci -v 00:05.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 [OHCI]) Flags: bus master, medium devsel, latency 128, IRQ 27 Memory at bffff800 (32-bit, non-prefetchable) [size=2K] Memory at bfff8000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 1 00:06.0 IDE interface: CMD Technology Inc: Unknown device 0680 (rev 01) (prog-if 85 [Master SecO PriO]) Subsystem: CMD Technology Inc: Unknown device 0680 Flags: bus master, medium devsel, latency 128, IRQ 28 I/O ports at fff8 [size=8] I/O ports at fff4 [size=4] I/O ports at ffe8 [size=8] I/O ports at ffe4 [size=4] I/O ports at ffd0 [size=16] Memory at bfff7f00 (32-bit, non-prefetchable) [size=256] Expansion ROM at [disabled] [size=512K] Capabilities: [60] Power Management version 2 00:07.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) Flags: bus master, medium devsel, latency 168, IRQ 30 Memory at bfff6000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=01, subordinate=01, sec-latency=176 Memory window 0: bfbf6000-bfff5000 (prefetchable) Memory window 1: 80000000-803ff000 I/O window 0: 0000bfd0-0000ffcf I/O window 1: 00004000-000040ff 16-bit legacy interface ports at 0001 00:07.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) Flags: bus master, medium devsel, latency 168, IRQ 30 Memory at bfbf5000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=02, sec-latency=176 Memory window 0: bf7f5000-bfbf4000 (prefetchable) Memory window 1: 80400000-807ff000 I/O window 0: 00007fd0-0000bfcf I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 02:00.0 Ethernet controller: Bridgecom, Inc: Unknown device 1985 (rev 11) Subsystem: Netgear: Unknown device 511a Flags: bus master, medium devsel, latency 32, IRQ 30 I/O ports at 8000 [size=256] Memory at 80400000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at bf800000 [size=128K] Capabilities: [c0] Power Management version 2 I'm not required to use a tulip-based card for my project. I'm considering using a 3c59x-based CardBus PC Card to see if I have any better luck. Any suggesstions? -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From profmakx@profmakx.org Fri Jan 31 10:42:01 2003 From: profmakx@profmakx.org (Markus Pfeiffer) Date: Fri Jan 31 10:42:01 2003 Subject: [tulip] Fwd: Cogent/Adaptec ANA 6144 Problem Message-ID: <200301310053.17063.profmakx@profmakx.org> On Monday 27 January 2003 15:14, you wrote: > On Mon, 27 Jan 2003, Markus Pfeiffer wrote: > > On Saturday 25 January 2003 16:28, you wrote: > > > On Fri, 24 Jan 2003, Markus Pfeiffer wrote: > > > > I have a server (Tualatin PIII, MSI Board) with Debian woody and > > > > debian kernel 2.4.20-686(-smp) and a an Cogent/Adaptec ANA 6144 board > > > > (4 Ports). When I plug my aDSL modem into the one Port and my > > > > internal net into the other this results in strange behaviour of the > > > > network. (When I connect using 2 RTL8139 everything works fine, so I > > > > think I can rule out other network/hardware problems). > > > > > > > > For example when I run "apt-get upgrade" the file transfer starts out > > > > pretty fast and at a certain point, it stops and I get "data socked > > > > timed out" error. Funny thing is: For example when installing > > > > libncurses5-dev it stops at 41% (deterministic :)). Only FYI, if you care. The cause for the hanging transfers and all the problems I had seemed to be an interrupt problem. I took out the risercard and all the other cards (network etc) and reinstalled them (well i plugged the interrupt line of the risercard in different slots). Now the interrupts are being assigned differently (now IRQ5 before IRQ11). I did a lot of different transfers now which hung before, now they work... well this seemed to be it (I also took care of the airflow, but that was before and the transfers didn't work then either) Markus From RWMarch@sympatico.ca Fri Jan 31 10:43:58 2003 From: RWMarch@sympatico.ca (Robert W March) Date: Fri Jan 31 10:43:58 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1043961253.14370.56.camel@kneedragger> References: <1043961253.14370.56.camel@kneedragger> Message-ID: <200301302207.34927.RWMarch@sympatico.ca> On January 30, 2003 16:14, Jim Rowe wrote: > Has this driver been known to work correctly with a CardBus interface on > the PPC? I'm working with some custom hardware and it would be helpful > to know if the driver has been tested on such a setup. > > Thanks, > Jim Hello Jim, I can tell you that I also have attempted to use a Netgear FA511 CardBus PC Card with both Donald's driver and, in my case, the kernel 2.4.18 driver. I have had no success either. The appropriate modules load OK, occasionally ping bytes are transmitted but few if any are received. I would like to see this card working but for now it is sitting on the shelf. I have gone back to using an NE2000 card. Others have reported on this list of failure with this card. The following are my results. You will notice that the eeprom contents have come up empty. On some occasions the eeprom contents were present but still the card did not function. # dmesg |grep PCI: PCI: PCI BIOS revision 2.10 entry at 0xfd880, last bus=7 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7110] at 00:07.0 PCI: Found IRQ 11 for device 00:07.2 PCI: Found IRQ 11 for device 00:02.0 PCI: Sharing IRQ 11 with 00:06.0 PCI: Sharing IRQ 11 with 01:00.0 PCI: Found IRQ 11 for device 00:02.1 PCI: Enabling device 05:00.0 (0000 -> 0003) PCI: Setting latency timer of device 05:00.0 to 64 # dmesg |grep cs: cs: cb_alloc(bus 5): vendor 0x1317, device 0x1985 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x130-0x137 0x200-0x207 0x220-0x22f 0 x388-0x38f 0x3b8-0x3df 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. # mii-diag Basic registers of MII PHY #1: 3100 786d 001d 2411 05e1 41e1 0007 2001. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3100: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. End of basic transceiver information. # tulip-diag -eee tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-C adapter at 0x4800. Comet duplex is reported in the MII status registers. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Comet MAC address registers 697a1000 ffff38f1 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. WARNING: The EEPROM is missing or erased! Ethernet MAC Station Address ff:ff:ff:ff:ff:ff. Default connection type 'Default'. PCI IDs Vendor ffff Device ffff Subsystem ffff ffff PCI min_grant 255 max_latency 255. CSR18 power-up setting 0xffff****. EEPROM contents (256 words): 0x00: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x08: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x10: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x18: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x20: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x28: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x30: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x38: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x40: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x48: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x50: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x58: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x60: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x68: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x70: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x78: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x80: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x88: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x90: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0x98: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xa0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xa8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xb0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xb8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xc0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xc8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xd0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xd8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff ________________ 0xf8: ffff ffff ffff ffff ffff ffff ffff ffff ________________ ID block CRC 0xfa (vs. 0xff). Full contents CRC 0x6a15 (read as 0xffff). # lspci -v 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03 ) Flags: bus master, medium devsel, latency 64 Memory at 40000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 168 Bus: primary=00, secondary=01, subordinate=01, sec-latency=176 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: 70000000-dfffffff Prefetchable memory behind bridge: e0000000-f7ffffff 00:02.0 CardBus bridge: Texas Instruments PCI1251A Subsystem: IBM: Unknown device 00eb Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 50102000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=04, sec-latency=176 Memory window 0: 12000000-123ff000 (prefetchable) Memory window 1: 12400000-127ff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 00:02.1 CardBus bridge: Texas Instruments PCI1251A Subsystem: IBM: Unknown device 00eb Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 50101000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=05, subordinate=07, sec-latency=176 Memory window 0: 12800000-12bff000 (prefetchable) Memory window 1: 12c00000-12fff000 I/O window 0: 00004800-000048ff I/O window 1: 00004c00-00004cff 16-bit legacy interface ports at 0001 00:06.0 Multimedia audio controller: Cirrus Logic CS 4610/11 [CrystalClear Sound Fusion Audio Accelerator] (rev 01) Subsystem: IBM CS4610 SoundFusion Audio Accelerator Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at 50100000 (32-bit, non-prefetchable) [size=4K] Memory at 50000000 (32-bit, non-prefetchable) [size=1M] 00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 48 [virtual] I/O ports at 01f0 [virtual] I/O ports at 03f4 [virtual] I/O ports at 0170 [virtual] I/O ports at 0374 I/O ports at fcf0 [size=16] 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 48, IRQ 11 I/O ports at 8400 [size=32] 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) Flags: medium devsel, IRQ 9 01:00.0 VGA compatible controller: Neomagic Corporation [MagicMedia 256AV] (rev 20) (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 00dd Flags: bus master, medium devsel, latency 128, IRQ 11 Memory at e0000000 (32-bit, prefetchable) [size=16M] Memory at 70000000 (32-bit, non-prefetchable) [size=4M] Memory at 70400000 (32-bit, non-prefetchable) [size=1M] Capabilities: [dc] Power Management version 1 05:00.0 Ethernet controller: Linksys Fast Ethernet 10/100 (rev 11) Subsystem: Netgear: Unknown device 511a Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 4800 [size=256] Memory at 12c00000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at 12800000 [size=128K] -Robert -- Robert March St Andrew's House L'Orignal ON K0B 1K0 From becker@scyld.com Fri Jan 31 11:12:01 2003 From: becker@scyld.com (Donald Becker) Date: Fri Jan 31 11:12:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <200301302207.34927.RWMarch@sympatico.ca> Message-ID: On Thu, 30 Jan 2003, Robert W March wrote: > On January 30, 2003 16:14, Jim Rowe wrote: > > Has this driver been known to work correctly with a CardBus interface on > > the PPC? I'm working with some custom hardware and it would be helpful > > to know if the driver has been tested on such a setup. .. > I can tell you that I also have attempted to use a Netgear FA511 CardBus PC > Card with both Donald's driver and, in my case, the kernel 2.4.18 driver. I > have had no success either. The appropriate modules load OK, occasionally > ping bytes are transmitted but few if any are received. I would like to see > this card working but for now it is sitting on the shelf. I have gone back > to using an NE2000 card. Others have reported on this list of failure with > this card. Has anyone with a PPC tried to the driver with a message level of 15? > The following are my results. You will notice that the eeprom contents have > come up empty. On some occasions the eeprom contents were present but still > the card did not function. ... > # tulip-diag -eee > tulip-diag.c:v2.16 12/17/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a ADMtek AL985 Centaur-C adapter at 0x4800. > Comet duplex is reported in the MII status registers. > Transmit started, Receive started. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 128. > Comet MAC address registers 697a1000 ffff38f1 > Comet multicast filter 0000000040000000. These are all correct. Is this on a PPC machine? If so, what distribution? Many PPC distributions in the past have had broken diagnostic interfaces (presumably because the people making the distribution didn't understand what the code was for). > EEPROM 256 words, 8 address bits. > WARNING: The EEPROM is missing or erased! -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri Jan 31 15:21:02 2003 From: becker@scyld.com (Donald Becker) Date: Fri Jan 31 15:21:02 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1044042480.22575.17.camel@kneedragger> Message-ID: On 31 Jan 2003, Jim Rowe wrote: > > Has anyone with a PPC tried to the driver with a message level of 15? > > There are additional messages when I try to ping something on the card's > subnet with a debug level of 15: > > Nov 30 18:01:19 eth0 kernel: tulip.c:v0.95f 11/17/2002 Written by > Donald Becker > Nov 30 18:01:19 eth0 kernel: http://www.scyld.com/network/tulip.html > Nov 30 18:01:19 eth0 kernel: eth1: ADMtek Centaur-C rev 17 at > 0xc902f000, 00:10:7A:69:F0:79, IRQ 30. > Nov 30 18:01:19 eth0 kernel: eth1: MII transceiver #1 config 1100 > status 7849 advertising 05e1. > Nov 30 18:11:08 eth0 kernel: eth1: MII link partner 0000, negotiated > 0000. > Nov 30 18:11:08 eth0 kernel: eth1: No link beat on the MII interface, > status 7849. I'm guessing that this is correct -- no cable connected. > Nov 30 18:11:11 eth0 kernel: eth1: MII link partner 0000, negotiated > 0000. > Nov 30 18:11:11 eth0 kernel: eth1: No link beat on the MII interface, > status 7849. > Nov 30 18:12:11 eth0 kernel: eth1: MII link partner 45e1, negotiated > 05e1. > Nov 30 18:12:11 eth0 kernel: eth1: Setting full-duplex based on MII #1 > link partner capability of 45e1. And now we get link beat. If you tried to ping, there should be more messages. Run 'dmesg', or config syslog to record the "debug" level messages from the kernel: echo "kern.* -/var/log/debug" >> /etc/syslog.conf -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rowejames@acmsystems.com Fri Jan 31 15:30:01 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Fri Jan 31 15:30:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? Message-ID: <1044041319.22575.5.camel@kneedragger> Hi Robert, > I have gone back > to using an NE2000 card. Others have reported on this list of failure with > this card. Is this NE2000 card you went back to a CardBus card (32-bit)? Is it working properly? -- Jim -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From rowejames@acmsystems.com Fri Jan 31 15:30:08 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Fri Jan 31 15:30:08 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1044041843.22575.14.camel@kneedragger> Hi Donald, > Has anyone with a PPC tried to the driver with a message level of 15? I just tried this on my PPC with 'insmod tulip.o debug=15'. Here is the log: root@eth0:/usr/src/netdrivers# dmesg root@eth0:/usr/src/netdrivers# lsmod Module Size Used by tulip 39392 0 (unused) pci-scan 3664 1 [tulip] ds 8688 0 (unused) yenta_socket 11792 2 pcmcia_core 42656 0 [ds yenta_socket] root@eth0:/usr/src/netdrivers# rmmod tulip root@eth0:/usr/src/netdrivers# insmod tulip.o debug=15 root@eth0:/usr/src/netdrivers# dmesg tulip.c:v0.95f 11/17/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html eth1: ADMtek Centaur-C rev 17 at 0xc902f000, 00:10:7A:69:F0:79, IRQ 30. eth1: MII transceiver #1 config 1100 status 7849 advertising 05e1. -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From rowejames@acmsystems.com Fri Jan 31 15:30:12 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Fri Jan 31 15:30:12 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1044042480.22575.17.camel@kneedragger> > Has anyone with a PPC tried to the driver with a message level of 15? There are additional messages when I try to ping something on the card's subnet with a debug level of 15: Nov 30 18:01:19 eth0 kernel: tulip.c:v0.95f 11/17/2002 Written by Donald Becker Nov 30 18:01:19 eth0 kernel: http://www.scyld.com/network/tulip.html Nov 30 18:01:19 eth0 kernel: eth1: ADMtek Centaur-C rev 17 at 0xc902f000, 00:10:7A:69:F0:79, IRQ 30. Nov 30 18:01:19 eth0 kernel: eth1: MII transceiver #1 config 1100 status 7849 advertising 05e1. Nov 30 18:11:08 eth0 kernel: eth1: MII link partner 0000, negotiated 0000. Nov 30 18:11:08 eth0 kernel: eth1: No link beat on the MII interface, status 7849. Nov 30 18:11:11 eth0 kernel: eth1: MII link partner 0000, negotiated 0000. Nov 30 18:11:11 eth0 kernel: eth1: No link beat on the MII interface, status 7849. Nov 30 18:12:11 eth0 kernel: eth1: MII link partner 45e1, negotiated 05e1. Nov 30 18:12:11 eth0 kernel: eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From becker@scyld.com Fri Jan 31 15:48:02 2003 From: becker@scyld.com (Donald Becker) Date: Fri Jan 31 15:48:02 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1044041319.22575.5.camel@kneedragger> Message-ID: On 31 Jan 2003, Jim Rowe wrote: > > I have gone back > > to using an NE2000 card. Others have reported on this list of failure with > > this card. > > Is this NE2000 card you went back to a CardBus card (32-bit)? Is it > working properly? All of the NE2000 card I know of are PCMCIA 16 bit (ISA-like) cards. That means no bus-mastering and slow timing, thus much simpler operation. There could be a CardBus NE2000 out there, but I doubt it. I usually get complaints about driver support the day after a new device is available. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rowejames@acmsystems.com Fri Jan 31 19:23:01 2003 From: rowejames@acmsystems.com (Jim Rowe) Date: Fri Jan 31 19:23:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: References: Message-ID: <1044053844.22577.24.camel@kneedragger> On Fri, 2003-01-31 at 12:21, Donald Becker wrote: > > If you tried to ping, there should be more messages. Run 'dmesg', or > config syslog to record the "debug" level messages from the kernel: > > echo "kern.* -/var/log/debug" >> /etc/syslog.conf Here is the dmesg log after I try to ping with debug == 15: Nov 30 00:02:35 eth0 kernel: pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.com/linux/drivers.html Nov 30 00:02:37 eth0 kernel: tulip.c:v0.95f 11/17/2002 Written by Donald Becker Nov 30 00:02:37 eth0 kernel: http://www.scyld.com/network/tulip.html Nov 30 00:02:37 eth0 kernel: The PCI BIOS has not enabled the device at 2/0! Updating PCI command 0003->0007. Nov 30 00:02:37 eth0 kernel: eth1: ADMtek Centaur-C rev 17 at 0xc902f000, 00:10:7A:69:F0:79, IRQ 30. Nov 30 00:02:37 eth0 kernel: eth1: MII transceiver #1 config 3100 status 7869 advertising 05e1. Nov 30 00:02:37 eth0 kernel: PCI latency timer (CFLT) is unreasonably low at 0. Setting to 32 clocks. Nov 30 00:04:28 eth0 kernel: eth1: tulip_open() irq 30. Nov 30 00:04:28 eth0 kernel: eth1: MII link partner 45e1, negotiated 05e1. Nov 30 00:04:28 eth0 kernel: eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. Nov 30 00:04:28 eth0 kernel: eth1: Done tulip_open(), CSR0 fff98000, CSR5 fc674014 CSR6 ff972113. Nov 30 00:04:31 eth0 kernel: eth1: Comet link status 786d partner capability 45e1. Nov 30 00:04:31 eth0 kernel: eth1: MII link partner 45e1, negotiated 05e1. Nov 30 00:05:31 eth0 kernel: eth1: Comet link status 786d partner capability 45e1. Nov 30 00:05:31 eth0 kernel: eth1: MII link partner 45e1, negotiated 05e1. Nov 30 00:06:31 eth0 kernel: eth1: Comet link status 786d partner capability 45e1. Nov 30 00:06:31 eth0 kernel: eth1: MII link partner 45e1, negotiated 05e1. Nov 30 00:07:31 eth0 kernel: eth1: Comet link status 786d partner capability 45e1. Nov 30 00:07:31 eth0 kernel: eth1: MII link partner 45e1, negotiated 05e1. Nov 30 00:08:31 eth0 kernel: eth1: Comet link status 786d partner capability 45e1. Nov 30 00:08:31 eth0 kernel: eth1: MII link partner 45e1, negotiated 05e1. And here is the output of mii-diag -v. Everything seems to be ok? : root@eth0:/usr/src/netdrivers# ./mii-diag -v eth1 mii-diag.c:v2.07 11/15/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the new SIOCGMIIPHY value on PHY 1 (BMCR 0x1100). The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x1100: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver information. MII PHY #1 transceiver registers: 1100 786d 001d 2411 05e1 45e1 0007 2001 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 20a7 0319 0000 0000 7490 0f0c ae8f 7514 2e5d 1428 8911 0444 0230 0000. Basic mode control register 0x1100: Auto-negotiation enabled. Basic mode status register 0x786d ... 786d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:07:49:--:--:--, model 1 rev. 1. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. -- Jim Rowe Advanced CounterMeasure Systems Email: jrowe@acmsystems.com From becker@scyld.com Fri Jan 31 19:31:01 2003 From: becker@scyld.com (Donald Becker) Date: Fri Jan 31 19:31:01 2003 Subject: [tulip] Tulip and PowerPC endian issue? In-Reply-To: <1044053844.22577.24.camel@kneedragger> Message-ID: On 31 Jan 2003, Jim Rowe wrote: > On Fri, 2003-01-31 at 12:21, Donald Becker wrote: > > > > If you tried to ping, there should be more messages. Run 'dmesg', or > > config syslog to record the "debug" level messages from the kernel: > > > > echo "kern.* -/var/log/debug" >> /etc/syslog.conf > > Here is the dmesg log after I try to ping with debug == 15: Hmmm, we are still not seeing the status messages. There should be messages for every interrupt and received packet. Are you getting a non-zero interrupt count in /proc/interrupts? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993