From alexander@netintact.se Sat Dec 1 18:39:00 2001 From: alexander@netintact.se (=?iso-8859-1?Q?Alexander_Hav=E4ng?=) Date: Sat Dec 1 18:39:00 2001 Subject: [tulip] Anyone running DFE-570-TX on an i815 based MB? Message-ID: <20011202003711.A4854@Q.netintact.se> We do, or did. Never had any lockups with it, but we only used one card in each box. But the reason we switched was that the performance on i815-based boards was significantly less than the VIA and ServerWorks based boards. Why this is.. I have no clue. But it must have something to do with the PCI architecture, perhaps the PCI version or some other i/o bus issues. Regards Alexander Haväng From orlandorocha@digi.com.br Sat Dec 1 19:20:00 2001 From: orlandorocha@digi.com.br (Orlando Rocha) Date: Sat Dec 1 19:20:00 2001 Subject: [tulip] Help-me Message-ID: <002c01c17ac6$b8b97640$0200a8c0@MESTRADO> This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C17AB5.F4C8BCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Help-me, I have notebook presario 1701LB, I installed kernel 2.4.7-10 and you see = the pci-list: PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev = 3). Master Capable. Latency=3D64.=20 Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3). Master Capable. Latency=3D96. Min Gnt=3D136. Bus 0, device 7, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 7, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=3D64.=20 I/O at 0x1090 [0x109f]. Bus 0, device 7, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 5. Master Capable. Latency=3D32.=20 I/O at 0x1060 [0x107f]. Bus 0, device 7, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 3). IRQ 9. Bus 0, device 8, function 0: CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller = (rev 1). IRQ 9. Master Capable. Latency=3D168. Min Gnt=3D192.Max Lat=3D5. Non-prefetchable 32 bit memory at 0x10000000 [0x10000fff]. Bus 0, device 9, function 0: Ethernet controller: PCI device 14f1:1803 (CONEXANT) (rev 8). IRQ 9. Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40. I/O at 0x1400 [0x14ff]. Non-prefetchable 32 bit memory at 0xf4000000 [0xf4003fff]. Bus 0, device 9, function 1: Communication controller: PCI device 14f1:1815 (CONEXANT) (rev 5). IRQ 9. Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40. I/O at 0x1080 [0x1087]. Non-prefetchable 32 bit memory at 0xf4004000 [0xf4007fff]. Bus 0, device 10, function 0: Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 18). IRQ 5. Master Capable. Latency=3D64. Min Gnt=3D2.Max Lat=3D24. I/O at 0x1800 [0x18ff]. Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility AGP = 2x (rev 100). IRQ 10. Master Capable. Latency=3D66. Min Gnt=3D8. Non-prefetchable 32 bit memory at 0xf5000000 [0xf5ffffff]. I/O at 0x2000 [0x20ff]. Non-prefetchable 32 bit memory at 0xf4100000 [0xf4100fff]. I tryed to install tulip for my network card, but I didn't manager and I = saw a error about interrupted and pci-card bus! I thanks to help me, Thanks a lot, Orlando Rocha ------=_NextPart_000_0029_01C17AB5.F4C8BCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Help-me,
I have notebook presario 1701LB, I = installed kernel=20 2.4.7-10 and you see the pci-list:

PCI devices found:

Bus 0, device 0, function 0:

Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev = 3).

Master Capable. Latency=3D64.

Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].

Bus 0, device 1, function 0:

PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev = 3).

Master Capable. Latency=3D96. Min Gnt=3D136.

Bus 0, device 7, function 0:

ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).

Bus 0, device 7, function 1:

IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).

Master Capable. Latency=3D64.

I/O at 0x1090 [0x109f].

Bus 0, device 7, function 2:

USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).

IRQ 5.

Master Capable. Latency=3D32.

I/O at 0x1060 [0x107f].

Bus 0, device 7, function 3:

Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 3).

IRQ 9.

Bus 0, device 8, function 0:

CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller = (rev=20 1).

IRQ 9.

Master Capable. Latency=3D168. Min Gnt=3D192.Max Lat=3D5.

Non-prefetchable 32 bit memory at 0x10000000 [0x10000fff].

Bus 0, device 9, function 0:

Ethernet controller: PCI device 14f1:1803 (CONEXANT) (rev 8).

IRQ 9.

Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40.

I/O at 0x1400 [0x14ff].

Non-prefetchable 32 bit memory at 0xf4000000 [0xf4003fff].

Bus 0, device 9, function 1:

Communication controller: PCI device 14f1:1815 (CONEXANT) (rev = 5).

IRQ 9.

Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40.

I/O at 0x1080 [0x1087].

Non-prefetchable 32 bit memory at 0xf4004000 [0xf4007fff].

Bus 0, device 10, function 0:

Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev = 18).

IRQ 5.

Master Capable. Latency=3D64. Min Gnt=3D2.Max Lat=3D24.

I/O at 0x1800 [0x18ff].

Bus 1, device 0, function 0:

VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility = AGP 2x=20 (rev 100).

IRQ 10.

Master Capable. Latency=3D66. Min Gnt=3D8.

Non-prefetchable 32 bit memory at 0xf5000000 [0xf5ffffff].

I/O at 0x2000 [0x20ff].

Non-prefetchable 32 bit memory at 0xf4100000 [0xf4100fff].

 

I tryed to install tulip for my network card, but = I didn't=20 manager and I saw a error about interrupted and pci-card bus!

I thanks to help me,

Thanks a lot,

Orlando Rocha

 
------=_NextPart_000_0029_01C17AB5.F4C8BCB0-- From erik@iks-jena.de Mon Dec 3 09:33:01 2001 From: erik@iks-jena.de (Erik Heinz) Date: Mon Dec 3 09:33:01 2001 Subject: [tulip] Adaptec ANA-6944A/TX In-Reply-To: ; from becker@scyld.com on Tue, Nov 06, 2001 at 05:52:18PM -0500 References: <3BE86388.2030706@candelatech.com> Message-ID: <20011203153223.A25521@iks-jena.de> Hi Donald and others, On Tue, Nov 06, 2001 at 05:52:18PM -0500, Donald Becker wrote: > > > On Tue, 6 Nov 2001, Ron Reed wrote: > > > > > >>Has anyone gotten the ANA-6944A/TX multiport ethernet card to work with > > >>RedHat 7.1? The kernel is 2.4.3-6. > With 2.2 and before, on x86 only, the driver itself hacks the IRQ > mapping to work around the common BIOS IRQ mapping bug where PCI chips > behind a bus bridge are assigned different IRQs, but the 4 port card is > interrupting only on INTA, a single IRQ line. > > With 2.4 the PCI subsystem controls the IRQ mapping, and fixes up this > common x86 bug. You can tell that this case has the fix-up implemented > because IRQ is the same on all interfaces. This obviously does not work with the Adaptec ANA-6944A/TX or similar cards. The problem has been discussed on this list several times but I have seen no solution yet. I would like to know what can be done to solve the problem. Is anyone working on it yet? Thank you, Erik -- | Erik Heinz, IKS GmbH Jena * erik@iks-jena.de * privat: erik@jena.thur.de | +---------------------------------------------------------------------------+ From johnconrad@chello.se Mon Dec 3 10:52:01 2001 From: johnconrad@chello.se (John Conrad) Date: Mon Dec 3 10:52:01 2001 Subject: [tulip] (no subject) Message-ID: From johnconrad@chello.se Mon Dec 3 10:56:03 2001 From: johnconrad@chello.se (John Conrad) Date: Mon Dec 3 10:56:03 2001 Subject: [tulip] =?iso-8859-1?Q?Compaq_10=5F100_MinI=EDPCI_Ethernet_Nic?= Message-ID: Hello- Is there a tulip driver that works with Compaq 10_100 MiniPCI Ethernet Nic on a Compaq 1700 with Red Hat 7.2? Thanks John Conrad From orlandorocha@digi.com.br Mon Dec 3 10:58:03 2001 From: orlandorocha@digi.com.br (Orlando Rocha) Date: Mon Dec 3 10:58:03 2001 Subject: [tulip] kernel 2.4.7-10 Message-ID: <001d01c17c13$56ac2670$fb06f9c8@MESTRADO> This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C17C02.929B61C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Where can I find the driver for tulip on the kernel 2.4.7-10? Thanks a lot, Orlando Rocha ------=_NextPart_000_0015_01C17C02.929B61C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
Where can I find the driver for tulip = on the kernel=20 2.4.7-10?
Thanks a lot,
Orlando = Rocha
------=_NextPart_000_0015_01C17C02.929B61C0-- From becker@scyld.com Mon Dec 3 11:26:01 2001 From: becker@scyld.com (Donald Becker) Date: Mon Dec 3 11:26:01 2001 Subject: [tulip] Adaptec ANA-6944A/TX In-Reply-To: <20011203153223.A25521@iks-jena.de> Message-ID: On Mon, 3 Dec 2001, Erik Heinz wrote: > > With 2.2 and before, on x86 only, the driver itself hacks the IRQ > > mapping to work around the common BIOS IRQ mapping bug where PCI chips > > behind a bus bridge are assigned different IRQs, but the 4 port card is > > interrupting only on INTA, a single IRQ line. > > > > With 2.4 the PCI subsystem controls the IRQ mapping, and fixes up this > > common x86 bug. You can tell that this case has the fix-up implemented > > because IRQ is the same on all interfaces. > > This obviously does not work with the Adaptec ANA-6944A/TX or similar > cards. The problem has been discussed on this list several times but > I have seen no solution yet. Please understand the actual problem, not just the symptoms. The problem is with the 2.4 kernel combined with your specific motherboard, not the tulip driver or Adaptec card. An IRQ mapping problem will occur with any board using the same bus bridge chip, not just the ANA-6944. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Mon Dec 3 11:31:01 2001 From: becker@scyld.com (Donald Becker) Date: Mon Dec 3 11:31:01 2001 Subject: [tulip] =?iso-8859-1?Q?Compaq_10=5F100_MinI=EDPCI_Ethernet_Nic?= In-Reply-To: Message-ID: On Mon, 3 Dec 2001, John Conrad wrote: > Is there a tulip driver that works with Compaq 10_100 MiniPCI > Ethernet Nic on a Compaq 1700 with Red Hat 7.2? Yes. This has been covered many times in the past few months. Look in the list archives for "Conexant". The simple answer is that only the Scyld driver works with the Conexant chip. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From erik@iks-jena.de Mon Dec 3 14:13:03 2001 From: erik@iks-jena.de (Erik Heinz) Date: Mon Dec 3 14:13:03 2001 Subject: [tulip] Adaptec ANA-6944A/TX In-Reply-To: ; from becker@scyld.com on Mon, Dec 03, 2001 at 11:32:10AM -0500 References: <20011203153223.A25521@iks-jena.de> Message-ID: <20011203201254.A20944@iks-jena.de> On Mon, Dec 03, 2001 at 11:32:10AM -0500, Donald Becker wrote: > > The problem is with the 2.4 kernel combined with your specific > motherboard, not the tulip driver or Adaptec card. An IRQ mapping > problem will occur with any board using the same bus bridge chip, not > just the ANA-6944. I have well understood that this is not a problem of the Tulip chipset or the Tulip drivers. It seems, however, to reveal particularly in the case of Tulip equipped 4-port cards. That's why it has been on topic here before and other readers of this list might be interested, too. My personal insight into kernel hacking is, alas, very limited and I am not able to solve the problem myself. I am turning to this list in the hope that either someone with enough knowledge of the PCI code in Linux 2.4 is reading here and could take a look at the problem or otherwise someone knows the right address to report it to the people in charge. Thank you, Erik -- | Erik Heinz, IKS GmbH Jena * erik@iks-jena.de * privat: erik@jena.thur.de | +---------------------------------------------------------------------------+ From Joerg.Dieter.Friedrich@uni-konstanz.de Mon Dec 3 17:05:01 2001 From: Joerg.Dieter.Friedrich@uni-konstanz.de (Joerg Friedrich) Date: Mon Dec 3 17:05:01 2001 Subject: [tulip] Problems with ADMtek Accton EN2242 Message-ID: <20011203225723.B7531@mail.terrania.city> Hi! I've got some problems with a Accton EN2242 CArd (MiniPCI): Tulip-driver reports that this card has no Interrupt assigned. I know this hints about changing BIOS-Settings to let BIOS assign the Interrupts, but this is no option, because BIOS does not have this option. My machine is a laptop (Gericom Supersonic2) and I didn't find any BIOS update. Any Hints? is there any possibility to assign interrupts by LILO-Bootprompt-Options, i.e. pci=... I tried pci=bios or pci=nobios, but there is no difference. I used a vanilla 2.2.20-kernel and patched the tulip-driver to v0.92. -- Heute ist nicht alle Tage, ich komm' wieder, keine Frage!!! Joerg Many are called, few volunteer. From dyoung@nettonettech.com Mon Dec 3 18:41:01 2001 From: dyoung@nettonettech.com (David Young) Date: Mon Dec 3 18:41:01 2001 Subject: [tulip] tulip on RH7.0 Message-ID: I am trying to install tulip on RH7.0 (2.2.16-22enterprise). I have read the special instructions for RH7.0 at http://www.scyld.com/network/updates.html I have tried both the rpm and compiling the individual driver. Any suggestions? RPM ATTEMPT: ----------------------------------------------------------- rpm -Uvh --force netdrivers-rh70.i386.rpm depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/3c59x.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/eepro100.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/epic100.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/hamachi.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/natsemi.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/ne2k-pci.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/rtl8139.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/starfire.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/sundance.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/tulip.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/tulip_20011202.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/tulip_orig.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/via-rhine.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/winbond-840.o depmod: *** Unresolved symbols in /lib/modules/2.2.16-22enterprise/net/yellowfin.o netdriver ################################################## [root@mail redhat]# cd /lib/modules/2.2.16-22enterprise/net/ [root@mail net]# insmod pci-scan.o [root@mail net]# insmod tulip.o tulip.o: unresolved symbol dev_close_Rsmpab086563 tulip.o: unresolved symbol netif_rx_Rsmp0a3fcdc4 tulip.o: unresolved symbol eth_type_trans_Rsmp02771567 tulip.o: unresolved symbol skb_over_panic_Rsmp4f682074 tulip.o: unresolved symbol init_etherdev_Rsmp3808c591 tulip.o: unresolved symbol __kfree_skb_Rsmp088bdac9 tulip.o: unresolved symbol alloc_skb_Rsmp40210a6a tulip.o: unresolved symbol eth_copy_and_sum_Rsmp0235d0cb tulip.o: unresolved symbol unregister_netdev_Rsmpe24126b3 SOURCE ATTEMPT: ----------------------------------------------------------- [root@mail tulip]# kgcc -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -Wall -Wstrict-prototypes -O6 -I/usr/src/linux/include -c pci-scan.c In file included from /usr/src/linux/include/linux/sched.h:20, from /usr/src/linux/include/linux/mm.h:4, from pci-scan.c:60: /usr/src/linux/include/linux/smp.h:77: warning: `smp_num_cpus' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:28: warning: this is the location of the previous definition /usr/src/linux/include/linux/smp.h:83: warning: `smp_call_function' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:118: warning: this is the location of the previous definition In file included from /usr/src/linux/include/linux/sched.h:74, from /usr/src/linux/include/linux/mm.h:4, from pci-scan.c:60: /usr/src/linux/include/asm/processor.h:96: warning: `cpu_data' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:6: warning: this is the location of the previous definition /tmp/cc2TJZu4.s: Assembler messages: /tmp/cc2TJZu4.s:26: Warning: Ignoring changed section attributes for .modinfo [root@mail tulip]# kgcc -DMODULE -Wall -Wstrict-prototypes -O6 -I/usr/src/linux/include -c tulip.c In file included from /usr/src/linux/include/linux/sched.h:20, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from tulip.c:148: /usr/src/linux/include/linux/smp.h:77: warning: `smp_num_cpus' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:28: warning: this is the location of the previous definition /usr/src/linux/include/linux/smp.h:83: warning: `smp_call_function' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:118: warning: this is the location of the previous definition In file included from /usr/src/linux/include/linux/sched.h:74, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from tulip.c:148: /usr/src/linux/include/asm/processor.h:96: warning: `cpu_data' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:6: warning: this is the location of the previous definition In file included from /usr/src/linux/include/linux/interrupt.h:51, from tulip.c:149: /usr/src/linux/include/asm/hardirq.h:23: warning: `synchronize_irq' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:138: warning: this is the location of the previous definition In file included from /usr/src/linux/include/linux/interrupt.h:52, from tulip.c:149: /usr/src/linux/include/asm/softirq.h:75: warning: `synchronize_bh' redefined /usr/src/linux/include/linux/modules/i386_ksyms.ver:142: warning: this is the location of the previous definition /tmp/ccMItR6H.s: Assembler messages: /tmp/ccMItR6H.s:146: Warning: Ignoring changed section attributes for .modinfo From johnconrad@chello.se Tue Dec 4 02:09:01 2001 From: johnconrad@chello.se (John Conrad) Date: Tue Dec 4 02:09:01 2001 Subject: [tulip] MiniPCI Ethernet NIC, RedHat7.2 and tulip-0.92wax.tar Message-ID: Hi --- Rh7.2(kernel 2.4.7-10) does not recognize the compaq 10_100 MiniPCI Ethernet NIC in my compaq presario 1700 laptop. The tulip driver (tulip-0.92wax.tar) from Scyld is rumored to work with this MiniPCI NIC and RH7.2. When I try to to compile the driver I get a lot of unresolved symbol errors. IS THERE ANYONE who has sucessfully compiled (or in some manner installed)the tulip driver for this MiniPCI Ethernet NIC and RH7.2( and hopefully on a compaq presario 1700)? I would really appreciate step by step instructions. Thanks and feeling Dumb and desperate John Conrad From tsombakos_mark@emc.com Thu Dec 6 10:58:01 2001 From: tsombakos_mark@emc.com (tsombakos, mark) Date: Thu Dec 6 10:58:01 2001 Subject: [tulip] Tulip and ANA6911A/TX Message-ID: Hello! I'm having problems with the tulip driver included in RedHat 7.2. My first issue is, I can't tell what version is the "latest" tulip driver. 0.92-pre3(?) was 7.2's, we bumped up to 0.92-pre6 (dated Nov 3) with a new kernel. But on Sourceforge, it's up to 1.1.8, dated June 16, 2001... The problem I'm seeing - when I power cycle my pc and Linux loads, I don't get a link light. If I stop networking, rmmod the tulip driver, modprobe tulip, and restart networking, it's fine. In fact, after I power cycle, the driver says it can't find an MII transceiver. After I reload the driver, it finds it fine. Any idea? Here's the output of tulip-diag -aa -ee -mm before and after reloading the driver. What's more peculiar - I see that sometimes it finds the MII transceiver at a different address. When it does, the network also does not work. I suspect something with the hardware, but I haven't seen this problem with 2.2 versions of the kernel. Mark tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x1400. Digital DS21143 Tulip chip registers at 0x1400: 0x00: f9a08000 ffffffff ffffffff 1f376000 1f376200 f0200100 b2420200 f3fe0000 0x40: e0000000 fff483ff ffffffff 00000000 000020c7 ffff0001 fffbffff 8ffdc008 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000020c7. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1109, device 2a00. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:D1:1E:E1:9D. EEPROM transceiver/media description table. Leaf node at offset 40, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 23. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0000. 21143 MII reset sequence is 3 words: 0821 0001 0000. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. EEPROM contents (64 words): 0x00: 1109 2a00 0000 0000 0000 0000 0000 0000 0x08: 0001 0103 0000 1ed1 9de1 2800 0000 0000 0x10: 0000 0000 0000 0000 0800 9701 0003 2102 0x18: 0008 0300 0821 0001 0000 7800 01e0 5000 0x20: 1800 8c00 4102 0009 0705 0006 0821 0005 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 042a 6f35 ID block CRC 0x01 (vs. 0x01). Full contents CRC 0x6f35 (read as 0x6f35). No MII transceivers found! Internal autonegotiation state is 'Ability detect'. ------------------------- after: ------------------------- tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x1400. Digital DS21143 Tulip chip registers at 0x1400: 0x00: f9a08000 ffffffff ffffffff 1f6ab000 1f6ab200 f4000102 b20e0000 f3fe0000 0x40: e0000000 fff583ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff4c000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1109, device 2a00. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:D1:1E:E1:9D. EEPROM transceiver/media description table. Leaf node at offset 40, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 23. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0000. 21143 MII reset sequence is 3 words: 0821 0001 0000. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. EEPROM contents (64 words): 0x00: 1109 2a00 0000 0000 0000 0000 0000 0000 0x08: 0001 0103 0000 1ed1 9de1 2800 0000 0000 0x10: 0000 0000 0000 0000 0800 9701 0003 2102 0x18: 0008 0300 0821 0001 0000 7800 01e0 5000 0x20: 1800 8c00 4102 0009 0705 0006 0821 0005 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 042a 6f35 ID block CRC 0x01 (vs. 0x01). Full contents CRC 0x6f35 (read as 0x6f35). MII PHY found at address 1, status 0x7869. MII PHY #1 transceiver registers: 1000 786d 2000 5c01 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c41 0000 3000 a3b9 0080 8005 001b. Basic mode control register 0x1000: 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 08:00:17:--:--:--, model 0 rev. 1. Vendor/Part: National Semiconductor 83840A. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. Internal autonegotiation state is 'Autonegotiation disabled'. --------------------------- MII at a different address: --------------------------- tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x1400. Digital DS21143 Tulip chip registers at 0x1400: 0x00: f9a08000 ffffffff ffffffff 1f376000 1f376200 f0000102 b20e0000 f3fe0000 0x40: e0000000 fff583ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff4c000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1109, device 2a00. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:D1:1E:E1:9D. EEPROM transceiver/media description table. Leaf node at offset 40, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 23. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0000. 21143 MII reset sequence is 3 words: 0821 0001 0000. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. EEPROM contents (64 words): 0x00: 1109 2a00 0000 0000 0000 0000 0000 0000 0x08: 0001 0103 0000 1ed1 9de1 2800 0000 0000 0x10: 0000 0000 0000 0000 0800 9701 0003 2102 0x18: 0008 0300 0821 0001 0000 7800 01e0 5000 0x20: 1800 8c00 4102 0009 0705 0006 0821 0005 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 042a 6f35 ID block CRC 0x01 (vs. 0x01). Full contents CRC 0x6f35 (read as 0x6f35). MII PHY found at address 17, status 0x7869. MII PHY #17 transceiver registers: 1000 786d 2000 5c01 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c51 0000 3000 a3b9 0080 8005 001b. Basic mode control register 0x1000: 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 08:00:17:--:--:--, model 0 rev. 1. Vendor/Part: National Semiconductor 83840A. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. Internal autonegotiation state is 'Autonegotiation disabled'. From becker@scyld.com Thu Dec 6 12:30:04 2001 From: becker@scyld.com (Donald Becker) Date: Thu Dec 6 12:30:04 2001 Subject: [tulip] Tulip and ANA6911A/TX In-Reply-To: Message-ID: On Thu, 6 Dec 2001, tsombakos, mark wrote: > I'm having problems with the tulip driver included in > RedHat 7.2. My first issue is, I can't tell what version > is the "latest" tulip driver. 0.92-pre3(?) was 7.2's, > we bumped up to 0.92-pre6 (dated Nov 3) with a new kernel. > But on Sourceforge, it's up to 1.1.8, dated June 16, 2001... The most recent version from the original source tree is v0.93. Incremental releases have a version such as "0.93a" http://www.scyld.com/network/tulip.html ftp://www.scyld.com/pub/network/tulip.c The version in the kernel is a split from my releases, and has three dotted numbers as the version string. > The problem I'm seeing - when I power cycle my pc and > Linux loads, I don't get a link light. If I stop networking, > rmmod the tulip driver, modprobe tulip, and restart networking, > it's fine. In fact, after I power cycle, the driver says it > can't find an MII transceiver. After I reload the driver, > it finds it fine. You have a 21143 with MII transceiver. The driver version you are using does not correctly reset the transceiver. > The Tx process state is 'Waiting for Tx to finish'. Yup, the transmit path isn't configured correctly. > 21143 MII reset sequence is 3 words: 0821 0001 0000. Many boards do not have a reset sequence, and wouldn't experience this problem. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From orlandorocha@digi.com.br Sat Dec 8 08:12:01 2001 From: orlandorocha@digi.com.br (Orlando Rocha) Date: Sat Dec 8 08:12:01 2001 Subject: [tulip] To install PCI1410 Message-ID: <002201c17fe9$ecd25780$de08f9c8@MESTRADO> This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C17FD9.28B6E470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I'm tring to install my HCF modem and Network Card, but I need to = install Cardbus bridge Texas Instruments PCI1410 controller PCMCIA. I = didn't manager it!=20 I have the kernell 2.4.X. Who can help me? I need examples to install and do it! My notebook is a presario 1701LB. Thanks a lot, Orlando Rocha ------=_NextPart_000_001F_01C17FD9.28B6E470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
I'm tring to install my HCF modem and = Network Card,=20 but I need to install Cardbus bridge Texas Instruments PCI1410 = controller=20 PCMCIA. I didn't manager it!
I have the kernell 2.4.X.
Who can help me?
I need examples to install and do=20 it!
My notebook is a presario = 1701LB.
Thanks a lot,
Orlando = Rocha
------=_NextPart_000_001F_01C17FD9.28B6E470-- From welcome" To be removed from this list simply reply with remove in the subject line. Dear Webmaster, Okay you have a great web site? Submitted to all of the search engines? Even hired some college kid to "promote" you to all of the FFA boards that nobody ever reads? If so I guess that you monthly site traffic is probably in the region of 10 to 100 visitors if you are lucky and you are feeling rather depressed - right? Well we have the definitive answer - we positively guarantee you high quality, genuine traffic to your web site. We make just one 100% guaranteed and solid promise to you - "WE WILL GET PEOPLE LOOKING AT YOUR WEB SITE WITHIN A MONTH - AND IF WE DON'T GET THE AMOUNT OF VISITORS TO YOU THAT WE PROMISE YOU CAN HAVE YOUR MONEY BACK - period" Take a few seconds to see what you get from TrafficFusion.Com The Ultimate Traffic Source ! http://www.trafficfusion.com This the one and only package of it's kind you will never find a more complete source to drive traffic to your web site and it is only being offered for a limited time! Here's What You'll Get: 1,000 Guaranteed Visitors every month for one full year! ($19.95 Value every Month!) 5,000 FREE Banner Impressions Guaranteed every month for one full year! ($24.95 Value every Month!) $500 in FREE Keywords on a Major Search Engine! (That's 50,000 targeted visitors) Free Submission of your Press Release to over 2,500 Media Sources Nationwide every month for one full year! (That's $249 Value!) E-Mail over 1,000,000 Opt-in subscribers daily! Spam Free! (That's a $199 monthly Value) That's a yearly Value of Over $3500 Yours for less than you pay for hosting every month!! You'll Also Get "Guaranteed Hits Secrets Exposed" This package shows you how to generate up to 1,000 hits per hour anytime you want to (and even shows you how to make that 1,000 hits equal even more!). You will have Full Resale Rights to resell the "Guaranteed Hits Secrets Exposed" for any price you choose! (This sells daily on eBay for $199) You'll Also Get: Instant Access To To 1,000's of Resources! Free multi-submission to 100,000's of sites; Instantly! 1000's of FREE reports, ebooks, tutorials and more! Dozens of FREE traffic building tools! Huge collection of home-based internet business links and resources! FREE software including submission utilities, FREE ebook compiler software, meta-tag optimization tools, etc.! Links to over 10,000 FREE ad sites including search engines, classifieds, ffa pages, etc.! FREE webmaster services such as link and html checkers, keyword utilities, doorway page generators, color and graphics tools, etc. FREE web graphics for your website including logo templates, borders & backgrounds, buttons, ebook graphics ,etc. Plus much more! http://www.trafficfusion.com If you are serious about the success of your site give us a shot! There will never be another opportunity to get such a complete promotional package! This is not a quick fix! We will deliver traffic to your site month after month! This is a Full 1 Year membership in our program! We are the traffic professionals! Thanks http://www.trafficfusion.com From marinho@exatas.unisinos.br Tue Dec 11 13:36:01 2001 From: marinho@exatas.unisinos.br (Marinho Barcellos) Date: Tue Dec 11 13:36:01 2001 Subject: [tulip] still trying Message-ID: <3C164FD2.6CA3E702@exatas.unisinos.br> hello I'm still trying to get the Conexant nic to work. Last time Donald Becker said: > You must be running a full duplex link -- the Conexant chip reports > every transmit packet as a carrier error in full duplex mode. and later > To set the link to a specific speed and duplex, use the transceiver > setting described at > http://www.scyld.com/network/tulip.html Now I tried all possible medias, run tulip-diag and ifconfig and noted down the most relevant info. In brief: options=0,0 autoselect (default to 10baseT): errors=carrier>0,rx>0,tx=0 options=1,1 10base2: carrier=2*errors,errors>0,rx=tx=0 options=3,3 100baseTx: errors=carrier=rx=0,tx>0 options=6,6 100baseT4: rx=0,tx>0 options=9,9 MII 10baseT:errors=carrier=rx=tx=0 (Tx processing setup info) options=11,11 MII autoselect:errors=carrier=rx=tx=0 (Tx processing setup info) options=12,12 Serial 10baseT (no autosel):carrier=2*errors,errors>0,tx=rx=0 options=13,13 MII 100baseTx: errors=carrier=rx=tx=0 (Tx processing setup info) options=15,15 MII 100baseT4: errors=carrier=rx=tx=0 (Tx processing setup info) based on 'ifconfig eth0' and 'tulip-diag -famme' outputs. Well, it appears that when a media with MII transceiver is used, the Tx process state becomes 'Processing setup information', like below (for media 13): Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Processing setup information'. The transmit threshold is 72. MII PHY found at address 1, status 0x780d. MII PHY found at address 0, status 0x780d. MII PHY #1 transceiver registers: 2000 780d 0022 1720 0080 0000 0005 2001 2000 780d 0022 1720 0080 0000 0005 2001 2000 780d 0022 1720 0080 0000 0005 2001 0000 0000 0000 0000 01e1 2001 0000 8c08. Basic mode control register 0x2000: Auto-negotiation disabled! Speed fixed at 100 mbps, half-duplex. Basic mode status register 0x780d ... 780d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:08:85:--:--:--, model 50 rev. 0. No specific information is known about this transceiver type. I'm advertising 0080: 100baseTx Advertising no additional info pages. Using an unknown (non 802.3) encapsulation. Link partner capability is 0000:. Negotiation did not complete. I guess it should work with options=3 (100baseTx) tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Conexant LANfinity chip registers at 0x1400: 0x00: fff88000 ffffffff ffffffff 0e081000 0e081200 f4660000 f8e02002 7bffebef 0x40: fffe0000 fffd80e8 fffe0000 fffe0000 ffffffff ffffffff ffffffff f7f9fec8 Extended registers: 80: cc660000 cbffebef f0000018 00000000 ffffffff 0e081290 0e081010 00000000 a0: ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 e0: 00000000 00000000 00000000 00000000 ffffffff 00000000 00000000 00000000 Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. MII PHY found at address 1, status 0x780d. MII PHY found at address 0, status 0x780d. MII PHY #1 transceiver registers: 2000 780d 0022 1720 0080 0000 0005 2001 2000 780d 0022 1720 0080 0000 0005 2001 2000 780d 0022 1720 0080 0000 0005 2001 0000 0000 0000 0000 01e1 2001 0000 8c08. Basic mode control register 0x2000: Auto-negotiation disabled! Speed fixed at 100 mbps, half-duplex. Basic mode status register 0x780d ... 780d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:08:85:--:--:--, model 50 rev. 0. No specific information is known about this transceiver type. I'm advertising 0080: 100baseTx Advertising no additional info pages. Using an unknown (non 802.3) encapsulation. Link partner capability is 0000:. Negotiation did not complete. eth0 Link encap:Ethernet HWaddr 00:50:8B:AB:1A:80 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:420 (420.0 b) Interrupt:9 Base address:0x1000 and, for 0 (autonegotiation): tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. MII PHY found at address 1, status 0x782d. MII PHY found at address 0, status 0x782d. MII PHY #1 transceiver registers: 1000 782d 0022 1720 01e1 45e1 0007 2001 1000 782d 0022 1720 01e1 45e1 0007 2001 1000 782d 0022 1720 01e1 0000 0007 2001 0000 0000 0000 0020 01e1 2001 0000 9c18. Basic mode control register 0x1000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:08:85:--:--:--, model 50 rev. 0. No specific information is known about this transceiver type. I'm advertising 01e1: 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. eth0 Link encap:Ethernet HWaddr 00:50:8B:AB:1A:80 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8498 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:6 dropped:0 overruns:0 carrier:6 collisions:0 txqueuelen:100 RX bytes:1388814 (1.3 Mb) TX bytes:0 (0.0 b) Interrupt:9 Base address:0x1000 So, for some cases it only transmits, while for others it only receives... Anyone can help? Anything I could change in the driver? Anything related to the switch port to which the notebook is connected (though windows works perfectly :^( ? Thanks. Marinho. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= Prof. Marinho Barcellos marinho@exatas.unisinos.br PIP/CA - Centro 6 http://www.inf.unisinos.br/~marinho/ UNISINOS - Universidade do Vale do Rio dos Sinos Av. Unisinos, 950 Phone: (051) 590-3333 ext.1639 Sao Leopoldo, RS, Brazil CEP 93022-000 FAX 5908162 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= From becker@scyld.com Tue Dec 11 14:10:00 2001 From: becker@scyld.com (Donald Becker) Date: Tue Dec 11 14:10:00 2001 Subject: [tulip] still trying In-Reply-To: <3C164FD2.6CA3E702@exatas.unisinos.br> Message-ID: On Tue, 11 Dec 2001, Marinho Barcellos wrote: > I'm still trying to get the Conexant nic to work. Last time > Donald Becker said: > > > You must be running a full duplex link -- the Conexant chip reports > > every transmit packet as a carrier error in full duplex mode. > and later > > To set the link to a specific speed and duplex, use the transceiver > > setting described at > > http://www.scyld.com/network/tulip.html > > Now I tried all possible medias, run tulip-diag and ifconfig and noted down > the most relevant info. In brief: What driver version are you using? What is the detection message? What does 'mii-diag' report? > options=0,0 autoselect (default to 10baseT): errors=carrier>0,rx>0,tx=0 > options=9,9 MII 10baseT:errors=carrier=rx=tx=0 (Tx processing setup info) > options=11,11 MII autoselect:errors=carrier=rx=tx=0 (Tx processing setup info) > options=12,12 Serial 10baseT (no autosel):carrier=2*errors,errors>0,tx=rx=0 > options=13,13 MII 100baseTx: errors=carrier=rx=tx=0 (Tx processing setup info) > options=15,15 MII 100baseT4: errors=carrier=rx=tx=0 (Tx processing setup info) The "processing setup information" likely means that you are using a driver that hasn't correctly initialized the chip. > MII PHY #1 transceiver registers: > 2000 780d 0022 1720 0080 0000 0005 2001 > 2000 780d 0022 1720 0080 0000 0005 2001 > 2000 780d 0022 1720 0080 0000 0005 2001 > 0000 0000 0000 0000 01e1 2001 0000 8c08. > Basic mode control register 0x2000: Auto-negotiation disabled! > Speed fixed at 100 mbps, half-duplex. This is the expected output when the speed and duplex are forced. > I guess it should work with options=3 (100baseTx) That sets the chip for a SYM transceiver. It has an on-chip MII transceiver. > and, for 0 (autonegotiation): > > tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Conexant LANfinity adapter at 0x1400. > Port selection is MII, full-duplex. > Transmit started, Receive started, full-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 128. This looks normal. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From marinho@exatas.unisinos.br Tue Dec 11 15:13:01 2001 From: marinho@exatas.unisinos.br (Marinho Barcellos) Date: Tue Dec 11 15:13:01 2001 Subject: [tulip] still trying References: Message-ID: <3C166590.8340E430@exatas.unisinos.br> Donald Becker wrote: > > I'm still trying to get the Conexant nic to work. Last time > What driver version are you using? v0.93, as reported in syslog (btw, a 2.4.14 system, mandrake) > What is the detection message? (using mode 13) from syslog: Dec 11 17:41:50 tyne kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker Dec 11 17:41:50 tyne kernel: http://www.scyld.com/network/tulip.html Dec 11 17:41:50 tyne kernel: The PCI BIOS has not enabled the device at 0/72! Updating PCI command 0003->0007. Dec 11 17:41:50 tyne kernel: eth0: Conexant LANfinity rev 8 at 0xd0a51000, 00:50:8B:AB:1A:80, IRQ 9. Dec 11 17:41:50 tyne kernel: eth0: Transceiver selection forced to MII 100baseTx. Dec 11 17:41:50 tyne kernel: eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. Dec 11 17:41:50 tyne kernel: eth0: Advertising 0080 on PHY 1, previously advertising 01e1. Dec 11 17:41:50 tyne kernel: eth0: MII transceiver #0 config 2000 status 780d advertising 0080. > What does 'mii-diag' report? [root@tyne diag]# mii-diag -vw eth0 mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html SIOCGMIIPHY on eth0 failed: Operation not supported > The "processing setup information" likely means that you are using a > driver that hasn't correctly initialized the chip. > > > I guess it should work with options=3 (100baseTx) > > That sets the chip for a SYM transceiver. It has an on-chip MII > transceiver. right, so it should work with 13, but is experiencing a problem during initialization. cheers Marinho. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= Prof. Marinho Barcellos marinho@exatas.unisinos.br PIP/CA - Centro 6 http://www.inf.unisinos.br/~marinho/ UNISINOS - Universidade do Vale do Rio dos Sinos Av. Unisinos, 950 Phone: (051) 590-3333 ext.1639 Sao Leopoldo, RS, Brazil CEP 93022-000 FAX 5908162 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= From michael.thaler@Physik.TU-Muenchen.DE Wed Dec 12 10:47:01 2001 From: michael.thaler@Physik.TU-Muenchen.DE (Michael Thaler) Date: Wed Dec 12 10:47:01 2001 Subject: [tulip] W-LINX LinxPRO Ethernet Message-ID: <20011212164634.A8361@xi.cip.physik.tu-muenchen.de> Hello, I bought a cheap W-LINX LinxPRO Ethernet 10/100 MBit pcmcia cardbus network card. When I plug the card into my computer the computer makes 2 high beeps and the computer recognizes the card. It prints out something like recognized tulip chipset but it cannot find the EEPROM. (I don't exactly remember and I don't have my computer with me right now). When I plug in the network cable (a crosslink cable, the other end attached to an 10 MBit card) it tells me that it detected a 10 MBit link. Both of the link LED are on. But when I try to ping a computer on the network, all packets are lost in both directions. Is there any chance to get the card working with linux? What can I do? Thanks, Michael From becker@scyld.com Wed Dec 12 12:55:01 2001 From: becker@scyld.com (Donald Becker) Date: Wed Dec 12 12:55:01 2001 Subject: [tulip] W-LINX LinxPRO Ethernet In-Reply-To: <20011212164634.A8361@xi.cip.physik.tu-muenchen.de> Message-ID: On Wed, 12 Dec 2001, Michael Thaler wrote: > I bought a cheap W-LINX LinxPRO Ethernet 10/100 MBit pcmcia cardbus > network card. When I plug the card into my computer the computer makes > 2 high beeps and the computer recognizes the card. It prints out > something like recognized tulip chipset but it cannot find the > EEPROM. (I don't exactly remember and > I don't have my computer with me right now). When I plug in the What is the detection message, including the driver version? Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From j-schroeder@myrealbox.com Wed Dec 12 17:00:01 2001 From: j-schroeder@myrealbox.com (Jacob Schroeder) Date: Wed Dec 12 17:00:01 2001 Subject: [tulip] LNE100TX rev. 5.0 Message-ID: <20011212155910.7f92d2bb.j-schroeder@myrealbox.com> I've got a Linksys LNE100TX that is marked ver. 5.0 on the board and 4.1 on the chipset. It's seems to be working fine as far as the driver finding it and being able to access the network and all, but my problem is that I've had an unusually large number of packet collisions since I hooked this NIC upto the network. I've got 5 sometimes 6 computers on the network counting the firewall, all going through the 8 port hub. My machine with the LNE100TX is the fileserver for the LAN. In just a couple hours ifconfig tells me I've had 65,832 packet collisions on this NIC. I think the problem is just that the NIC is trying to use full duplex instead of half, so I tried using "insmod tulip debug=1 options=9" and "insmod tulip debug=1 options=12" as seen on the www.scyld.com site but I'm still having the problem. Is there something I'm missing or does this NIC not support those options? TIA, Jacob BTW - system specs are Debian 2.2r4 on a 1Ghz Athlon w/256MB Ram. The tulip driver is version 0.91 loading as a module at boot time. ----- Windows: 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. Linux: The ultimate windows patch. http://www.linux.org/ From j-schroeder@myrealbox.com Wed Dec 12 23:40:00 2001 From: j-schroeder@myrealbox.com (Jacob Schroeder) Date: Wed Dec 12 23:40:00 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: References: <20011212155910.7f92d2bb.j-schroeder@myrealbox.com> Message-ID: <20011212223905.2d584e35.j-schroeder@myrealbox.com> Pardon my questions if I seem like a newbie, I'm still trying to learn. I had the network setup the same way and never had a problem with an older linksys ISA that was ne2000 compatible, so why would I have so many collisions with the new card? This computer is also the only one on the network to have this many collisions in such a short amount of time. On a network going through a properly sized hub shouldn't network errors be few? And Full Duplex would cause more collisions? I've got 5 sometimes 6 computers on an 8 port hub, with the only traffice being sharing a dialup and a fileserver. I can get roughly 6,000 errors just doing a 4 minute ssh connection with another computer on the lan, and those two computers being the only traffic going through the hub Thanks, Jacob On Wed, 12 Dec 2001 15:14:14 -0800 (PST) "..." wrote: > collisions are a normal behaviour through a hub. if you were running full > duplex you would have 0 collisions. so its working properly. > > On Wed, 12 Dec 2001, Jacob Schroeder wrote: > > > I've got a Linksys LNE100TX that is marked ver. 5.0 on the board and 4.1 on the chipset. It's seems to be working fine as far as the driver finding it and being able to access the network and all, but my problem is that I've had an unusually large number of packet collisions since I hooked this NIC upto the network. I've got 5 sometimes 6 computers on the network counting the firewall, all going through the 8 port hub. My machine with the LNE100TX is the fileserver for the LAN. In just a couple hours ifconfig tells me I've had 65,832 packet collisions on this NIC. I think the problem is just that the NIC is trying to use full duplex instead of half, so I tried using "insmod tulip debug=1 options=9" and "insmod tulip debug=1 options=12" as seen on the www.scyld.com site but I'm still having the problem. > > > > Is there something I'm missing or does this NIC not support those options? > > > > TIA, > > Jacob > > > > BTW - system specs are Debian 2.2r4 on a 1Ghz Athlon w/256MB Ram. The tulip driver is version 0.91 loading as a module at boot time. > > > > ----- > > Windows: > > > > 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit > > operating system originally coded for a 4 bit microprocessor, written > > by a 2 bit company, that can't stand 1 bit of competition. > > > > Linux: > > > > The ultimate windows patch. > > > > http://www.linux.org/ > > _______________________________________________ > > tulip mailing list, tulip@scyld.com > > To change to digest mode or unsubscribe visit > > http://www.scyld.com/mailman/listinfo/tulip > > > > -- > [-] Omae no subete no kichi wa ore no mono da. [-] > > ----- Windows: 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. Linux: The ultimate windows patch. http://www.linux.org/ From orlandorocha@digi.com.br Thu Dec 13 13:10:00 2001 From: orlandorocha@digi.com.br (Orlando Rocha) Date: Thu Dec 13 13:10:00 2001 Subject: [tulip] TULIP and CARDBUS TI PCI1410 Message-ID: <002f01c18401$877c2b60$0200a8c0@MESTRADO> This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C183F0.BDDCABF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I tried to install the driver TULIP and you see this message: Using /lib/modules/2.4.7-10custom/kernel/drivers/net/tulip/tulip.o Hint: insmod errors can be caused by incorrect module parameters, = including invalid IO or IRQ parameters When I do lsmod and I have the following modules: ds.................................................6928..................= ..............1=20 yenta_socket.............................9232............................= ....1=20 pcmcia_core............................41056.............................= ...0.........................[ds yenta_socket] pci-scan.....................................3504........................= .........0.........................(unused) My list of the PCI following: Bus 0, device 7, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 3). IRQ 9. Bus 0, device 8, function 0: CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller = (rev 1). IRQ 9. Master Capable. Latency=3D168. Min Gnt=3D192.Max Lat=3D5. Non-prefetchable 32 bit memory at 0x10000000 [0x10000fff]. Bus 0, device 9, function 0: Ethernet controller: PCI device 14f1:1803 (CONEXANT) (rev 8). IRQ 9. Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40. I/O at 0x1400 [0x14ff]. Non-prefetchable 32 bit memory at 0xf4000000 [0xf4003fff]. Bus 0, device 9, function 1: Communication controller: PCI device 14f1:1815 (CONEXANT) (rev 5). IRQ 9. Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40. I/O at 0x1080 [0x1087]. Non-prefetchable 32 bit memory at 0xf4004000 [0xf4007fff]. I have read some HOWTOs but I didn't manager, what can I do it about? = Who did already install notebook presario 1700? I thank to help me, I need some idea about this problem. Thanks a lot. Orlando Rocha ------=_NextPart_000_002C_01C183F0.BDDCABF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I tried to install the driver TULIP and = you see=20 this message:
 

Using = /lib/modules/2.4.7-10custom/kernel/drivers/net/tulip/tulip.o

Hint: insmod errors can be caused by incorrect module parameters, = including=20 invalid IO or IRQ parameters

When I do lsmod and I have the following=20 modules:

ds.................................................6928...............= .................1=20

yenta_socket.............................9232.........................= .......1=20

pcmcia_core............................41056..........................= ......0.........................[ds=20 yenta_socket]

pci-scan.....................................3504.....................= ............0.........................(unused)

My list of the PCI following:

Bus 0, device 7, function 3:

Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 3).

IRQ 9.

Bus 0, device 8, function 0:

CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller = (rev=20 1).

IRQ 9.

Master Capable. Latency=3D168. Min Gnt=3D192.Max Lat=3D5.

Non-prefetchable 32 bit memory at 0x10000000 [0x10000fff].

Bus 0, device 9, function 0:

Ethernet controller: PCI device 14f1:1803 (CONEXANT) (rev 8).

IRQ 9.

Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40.

I/O at 0x1400 [0x14ff].

Non-prefetchable 32 bit memory at 0xf4000000 [0xf4003fff].

Bus 0, device 9, function 1:

Communication controller: PCI device 14f1:1815 (CONEXANT) (rev = 5).

IRQ 9.

Master Capable. Latency=3D160. Min Gnt=3D20.Max Lat=3D40.

I/O at 0x1080 [0x1087].

Non-prefetchable 32 bit memory at 0xf4004000 [0xf4007fff].

 

I have read some HOWTOs but I didn't = manager, what=20 can I do it about? Who did already install notebook presario = 1700?

I thank to help me, I need some idea = about this=20 problem.

 

Thanks a lot.

Orlando=20 Rocha

------=_NextPart_000_002C_01C183F0.BDDCABF0-- From goemon@anime.net Thu Dec 13 18:01:01 2001 From: goemon@anime.net (...) Date: Thu Dec 13 18:01:01 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: <20011212223905.2d584e35.j-schroeder@myrealbox.com> Message-ID: On Wed, 12 Dec 2001, Jacob Schroeder wrote: > On a network going through a properly sized hub shouldn't network > errors be few? it depends on the speed of the network and how much traffic you are pushing. > And Full Duplex would cause more collisions? no it would cause zero collisions. > I've got 5 sometimes 6 computers on an 8 port hub, with the only > traffice being sharing a dialup and a fileserver. I can get roughly > 6,000 errors just doing a 4 minute ssh connection with another computer > on the lan, and those two computers being the only traffic going through > the hub collisions are normal on half duplex, errors are not. your error counter should be 0. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] From marinho@exatas.unisinos.br Fri Dec 14 14:02:01 2001 From: marinho@exatas.unisinos.br (Marinho Barcellos) Date: Fri Dec 14 14:02:01 2001 Subject: [tulip] still trying References: Message-ID: <3C1A4973.F57A4BED@exatas.unisinos.br> Hello > > What is the detection message? > from syslog: > Dec 11 17:41:50 tyne kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker > Dec 11 17:41:50 tyne kernel: http://www.scyld.com/network/tulip.html > Dec 11 17:41:50 tyne kernel: The PCI BIOS has not enabled the device at 0/72! Updating PCI command 0003->0007. > Dec 11 17:41:50 tyne kernel: eth0: Conexant LANfinity rev 8 at 0xd0a51000, 00:50:8B:AB:1A:80, IRQ 9. > Dec 11 17:41:50 tyne kernel: eth0: Transceiver selection forced to MII 100baseTx. > Dec 11 17:41:50 tyne kernel: eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. > Dec 11 17:41:50 tyne kernel: eth0: Advertising 0080 on PHY 1, previously advertising 01e1. > Dec 11 17:41:50 tyne kernel: eth0: MII transceiver #0 config 2000 status 780d advertising 0080. Have I reached a dead end on this? Would Donald or someone else point out any directions (even if it's "forget it", "try rewriting the tulip driver" or "simply buy a 3com card"? :^( Any hope/help? thanks a lot Marinho. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= Prof. Marinho Barcellos marinho@exatas.unisinos.br PIP/CA - Centro 6 http://www.inf.unisinos.br/~marinho/ UNISINOS - Universidade do Vale do Rio dos Sinos Av. Unisinos, 950 Phone: (051) 590-3333 ext.1639 Sao Leopoldo, RS, Brazil CEP 93022-000 FAX 5908162 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= From becker@scyld.com Fri Dec 14 15:34:01 2001 From: becker@scyld.com (Donald Becker) Date: Fri Dec 14 15:34:01 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: <20011212155910.7f92d2bb.j-schroeder@myrealbox.com> Message-ID: On Wed, 12 Dec 2001, Jacob Schroeder wrote: > I've got a Linksys LNE100TX that is marked ver. 5.0 on the board and > 4.1 on the chipset. What is the full detection message, including the version number? > problem is that I've had an unusually large number of packet > collisions since I hooked this NIC upto the network. I've got 5 > sometimes 6 computers on the network counting the firewall, all going > through the 8 port hub. Is the "hub" a switch or repeater? I'm guessing a repeater, but please be specific about this when reporting collision problems. > My machine with the LNE100TX is the fileserver > for the LAN. In just a couple hours ifconfig tells me I've had 65,832 > packet collisions on this NIC. How many transmitted packets? Note that the Tulip chip reports all contention events, up to 15 per packet, while many older designs report only "had at least one collision this packet". > I think the problem is just that the > NIC is trying to use full duplex instead of half, No, there would be zero reported collisions if this machine were in full duplex mode. If some other machine is incorrectly set to full duplex, you would encounter many addition normal collisions as well as out-of-window errors. > BTW - system specs are Debian 2.2r4 on a 1Ghz Athlon w/256MB Ram. The > tulip driver is version 0.91 loading as a module at boot time. Try version 0.93 Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri Dec 14 15:36:00 2001 From: becker@scyld.com (Donald Becker) Date: Fri Dec 14 15:36:00 2001 Subject: [tulip] TULIP and CARDBUS TI PCI1410 In-Reply-To: <002f01c18401$877c2b60$0200a8c0@MESTRADO> Message-ID: On Thu, 13 Dec 2001, Orlando Rocha wrote: > I tried to install the driver TULIP and you see this message: What driver version? > Using /lib/modules/2.4.7-10custom/kernel/drivers/net/tulip/tulip.o > Hint: insmod errors can be caused by incorrect module parameters, > including invalid IO or IRQ parameters Ignore the text from this message. > Ethernet controller: PCI device 14f1:1803 (CONEXANT) (rev 8). This is a ... { "Conexant LANfinity", { 0x180314f1, 0xffffffff }, You should be using the v0.93 driver. > I have read some HOWTOs but I didn't manager, what can I do it about? > Who did already install notebook presario 1700? Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From j-schroeder@myrealbox.com Fri Dec 14 16:00:01 2001 From: j-schroeder@myrealbox.com (Jacob Schroeder) Date: Fri Dec 14 16:00:01 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: References: <20011212155910.7f92d2bb.j-schroeder@myrealbox.com> Message-ID: <20011214145925.06ced779.j-schroeder@myrealbox.com> Here's the full detection message as seen in "/var/log/messages". Dec 12 10:11:34 jacob kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa .gov Dec 12 10:11:34 jacob kernel: eth0: ADMtek Centaur-P rev 17 at 0xdc00, 00:04:5A: 52:C7:36, IRQ 11. The hub is a repeater (a somewhat old 10Mbps Linksys with 8 RJ-45 ports and 1 BNC). ifconfig for this NIC currently shows 382,699 RX packets, 993,522 TX packets and 232,851 collisions with 0 receive or transmit errors. I'll try 0.93 as soon as I can get everything compiled right. 0.91 is the newest tulip ver. Debian potato has right now (2.2.19 kernel). Thanks, Jacob On Fri, 14 Dec 2001 15:42:32 -0500 (EST) Donald Becker wrote: > On Wed, 12 Dec 2001, Jacob Schroeder wrote: > > > I've got a Linksys LNE100TX that is marked ver. 5.0 on the board and > > 4.1 on the chipset. > > What is the full detection message, including the version number? > > > problem is that I've had an unusually large number of packet > > collisions since I hooked this NIC upto the network. I've got 5 > > sometimes 6 computers on the network counting the firewall, all going > > through the 8 port hub. > > Is the "hub" a switch or repeater? I'm guessing a repeater, but please > be specific about this when reporting collision problems. > > > My machine with the LNE100TX is the fileserver > > for the LAN. In just a couple hours ifconfig tells me I've had 65,832 > > packet collisions on this NIC. > > How many transmitted packets? > > Note that the Tulip chip reports all contention events, up to 15 per > packet, while many older designs report only "had at least one collision this > packet". > > > I think the problem is just that the > > NIC is trying to use full duplex instead of half, > > No, there would be zero reported collisions if this machine were in full > duplex mode. If some other machine is incorrectly set to full duplex, > you would encounter many addition normal collisions as well as > out-of-window errors. > > > BTW - system specs are Debian 2.2r4 on a 1Ghz Athlon w/256MB Ram. The > > tulip driver is version 0.91 loading as a module at boot time. > > Try version 0.93 > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > > ----- Windows: 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. Linux: The ultimate windows patch. http://www.linux.org/ From michael.thaler@physik.tu-muenchen.de Fri Dec 14 16:30:01 2001 From: michael.thaler@physik.tu-muenchen.de (Michael Thaler) Date: Fri Dec 14 16:30:01 2001 Subject: [tulip] W-LINX LinxPRO Ethernet In-Reply-To: References: <20011212164634.A8361@xi.cip.physik.tu-muenchen.de> Message-ID: <20011214222036.A1965@physik.tu-muenchen.de> On Wed, Dec 12, 2001 at 01:03:35PM -0500, Donald Becker wrote: > What is the detection message, including the driver version? Linux PCMCIA Card Services 3.1.29 kernel build: 2.4.16 #2 Die Dez 11 10:47:33 CET 2001 options: [pci] [cardbus] [apm] Intel ISA/PCI/CardBus PCIC probe: PCI: Found IRQ 9 for device 00:0c.0 PCI: Found IRQ 9 for device 00:0c.1 PCI: Sharing IRQ 9 with 00:0a.0 Ricoh RL5C478 rev 80 PCI-to-CardBus at slot 00:0c, mem 0x10000000 host opts [0]: [isa irq] [io 3/6/1] [mem 3/6/1] [pci irq 9] [lat 168/176] [bus 2/5] host opts [1]: [isa irq] [io 3/6/1] [mem 3/6/1] [pci irq 9] [lat 168/176] [bus 6/9] ISA irqs (default) = 3,4,5,7,10 PCI status changes cs: cb_alloc(bus 2): vendor 0x13d1, device 0xab08 cs: cb_config(bus 2) cs: IO port probe 0x0100-0x04ff: excluding 0x220-0x22f 0x330-0x337 0x378-0x37f 0x388-0x38f 0x398-0x39f 0x3c0-0x3df 0x4d0-0x4d7 cs: IO port probe 0x0230-0x032f: clean. cs: IO port probe 0x0338-0x0377: clean. cs: IO port probe 0x0380-0x0387: clean. cs: IO port probe 0x0390-0x0397: clean. cs: IO port probe 0x03a0-0x03bf: clean. cs: IO port probe 0x03e0-0x04cf: clean. cs: IO port probe 0x04d8-0x04ff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0a00-0x0aff: clean. cs: IO port probe 0x0c00-0x0cff: clean. fn 0 bar 1: io 0x800-0x8ff fn 0 bar 2: mem 0x60060000-0x600603ff fn 0 rom: mem 0x60040000-0x6005ffff irq 9 cs: cb_enable(bus 2) bridge io map 0 (flags 0x21): 0x800-0x8ff bridge mem map 0 (flags 0x1): 0x60040000-0x60060fff tulip_attach(device 02:00.0) tulip.c:v0.91g-ppc 7/16/99 becker@scyld.com (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) eth0: Digital DS21143 Tulip rev 17 at 0x800, EEPROM not present, 00:4C:69:6E:75:79, IRQ 9. eth0: MII transceiver #1 config 3000 status 7849 advertising 01e1. eth0: 21143 10mbps sensed media. eth0: 21143 10baseT link beat good. The card works fine with Win2000 in my network on the same computer. When I send any packets with the linux drivers to my other computers ping tells me that all the packets are lost. It would be nice to get the card working, because it is pretty cheap. Thanks, Michael From becker@scyld.com Fri Dec 14 16:55:01 2001 From: becker@scyld.com (Donald Becker) Date: Fri Dec 14 16:55:01 2001 Subject: [tulip] still trying In-Reply-To: <3C1A4973.F57A4BED@exatas.unisinos.br> Message-ID: On Fri, 14 Dec 2001, Marinho Barcellos wrote: > > > What is the detection message? > > from syslog: > > Dec 11 17:41:50 tyne kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker > > Dec 11 17:41:50 tyne kernel: http://www.scyld.com/network/tulip.html ... > > Dec 11 17:41:50 tyne kernel: eth0: Transceiver selection forced to MII 100baseTx. OK, I set the options=13 and was able to reproduce this problem. The work-around is to pass no options, and then force the speed with mii-diag -F 100baseTx Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri Dec 14 17:00:02 2001 From: becker@scyld.com (Donald Becker) Date: Fri Dec 14 17:00:02 2001 Subject: [tulip] W-LINX LinxPRO Ethernet In-Reply-To: <20011214222036.A1965@physik.tu-muenchen.de> Message-ID: On Fri, 14 Dec 2001, Michael Thaler wrote: > On Wed, Dec 12, 2001 at 01:03:35PM -0500, Donald Becker wrote: > > > What is the detection message, including the driver version? ... > tulip.c:v0.91g-ppc 7/16/99 becker@scyld.com (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) > eth0: Digital DS21143 Tulip rev 17 at 0x800, EEPROM not present, 00:4C:69:6E:75:79, IRQ 9. Hmmm, the driver was not able to read the EEPROM. > eth0: MII transceiver #1 config 3000 status 7849 advertising 01e1. > eth0: 21143 10mbps sensed media. > eth0: 21143 10baseT link beat good. Hmmm, my driver releases should only use the MII transceiver if one is found. I suspect one of the modifications changed the behavior, in this case breaking the driver. Keep in mind, though, that the primary problem is reading the EEPROM, not the fall-back media selection. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri Dec 14 17:03:01 2001 From: becker@scyld.com (Donald Becker) Date: Fri Dec 14 17:03:01 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: <20011214145925.06ced779.j-schroeder@myrealbox.com> Message-ID: On Fri, 14 Dec 2001, Jacob Schroeder wrote: > Here's the full detection message as seen in "/var/log/messages". > Dec 12 10:11:34 jacob kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa > .gov > Dec 12 10:11:34 jacob kernel: eth0: ADMtek Centaur-P rev 17 at 0xdc00, 00:04:5A: > 52:C7:36, IRQ 11. > > The hub is a repeater (a somewhat old 10Mbps Linksys with 8 RJ-45 > ports and 1 BNC). ifconfig for this NIC currently shows 382,699 RX > packets, 993,522 TX packets and 232,851 collisions with 0 receive or > transmit errors. These might be reasonable numbers for a busy network on a 10Mbps repeater. Just check /proc/net/dev (not 'ifconfig' or 'netstat -i') to verify that you don't have errors. > I'll try 0.93 as soon as I can get everything compiled right. 0.91 is > the newest tulip ver. Debian potato has right now (2.2.19 kernel). http://www.scyld.com/network/tulip.html ftp://www.scyld.com/pub/network/tulip.c Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From michael.thaler@physik.tu-muenchen.de Fri Dec 14 17:15:00 2001 From: michael.thaler@physik.tu-muenchen.de (Michael Thaler) Date: Fri Dec 14 17:15:00 2001 Subject: [tulip] W-LINX LinxPRO Ethernet In-Reply-To: References: <20011214222036.A1965@physik.tu-muenchen.de> Message-ID: <20011214230550.A3344@physik.tu-muenchen.de> On Fri, Dec 14, 2001 at 05:08:35PM -0500, Donald Becker wrote: > > tulip.c:v0.91g-ppc 7/16/99 becker@scyld.com (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) > > eth0: Digital DS21143 Tulip rev 17 at 0x800, EEPROM not present, 00:4C:69:6E:75:79, IRQ 9. > > Hmmm, the driver was not able to read the EEPROM. > > > eth0: MII transceiver #1 config 3000 status 7849 advertising 01e1. > > eth0: 21143 10mbps sensed media. > > eth0: 21143 10baseT link beat good. > > Hmmm, my driver releases should only use the MII transceiver if one is > found. I suspect one of the modifications changed the behavior, in this > case breaking the driver. Keep in mind, though, that the primary problem > is reading the EEPROM, not the fall-back media selection. Is there any chance to get the card working or it is better to just bring the card back and get another one? I am not a programmer and I can definitely not hack the driver, but if I can help in any way to get the card working, just tell me what I should do. Will it help to look for the resources the Win2000 driver uses? I know there is a tulip-diag programm, will that help? What else can I do? Greetings, Michael Thaler From j-schroeder@myrealbox.com Fri Dec 14 17:34:01 2001 From: j-schroeder@myrealbox.com (Jacob Schroeder) Date: Fri Dec 14 17:34:01 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: References: <20011214145925.06ced779.j-schroeder@myrealbox.com> Message-ID: <20011214163343.44f1a0c8.j-schroeder@myrealbox.com> On Fri, 14 Dec 2001 17:11:29 -0500 (EST) Donald Becker wrote: > On Fri, 14 Dec 2001, Jacob Schroeder wrote: > > > Here's the full detection message as seen in "/var/log/messages". > > Dec 12 10:11:34 jacob kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa > > .gov > > Dec 12 10:11:34 jacob kernel: eth0: ADMtek Centaur-P rev 17 at 0xdc00, 00:04:5A: > > 52:C7:36, IRQ 11. > > > > > The hub is a repeater (a somewhat old 10Mbps Linksys with 8 RJ-45 > > ports and 1 BNC). ifconfig for this NIC currently shows 382,699 RX > > packets, 993,522 TX packets and 232,851 collisions with 0 receive or > > transmit errors. > > These might be reasonable numbers for a busy network on a 10Mbps > repeater. Just check /proc/net/dev (not 'ifconfig' or 'netstat -i') to > verify that you don't have errors. > > > I'll try 0.93 as soon as I can get everything compiled right. 0.91 is > > the newest tulip ver. Debian potato has right now (2.2.19 kernel). > > http://www.scyld.com/network/tulip.html > ftp://www.scyld.com/pub/network/tulip.c > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > > /proc/net/dev reports no errors for eth0. With 5 computers hooked up to the network but none talking, I can get a little over 150 collisions just doing 10 pings to another Linux machine. So that's why I was a little concerned, but from what I'm hearing I guess that's not too abnormal. I'm not sure I'll be able to upgrade to the 0.93 driver for a while, I don't want to bother this list with my trivial problems of not being able to successfully compile them. I've done the kernel on numerous occasions, and read all the documentation for tulip, but I'm still not successful. Thanks for all you guys do for the open source community. I wish there were something more I could do to contribute back to the community but I guess I need to learn more programming first (or get a job so I can make a $ donation :-) Thanks again, Jacob From becker@scyld.com Fri Dec 14 17:59:00 2001 From: becker@scyld.com (Donald Becker) Date: Fri Dec 14 17:59:00 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: <20011214163343.44f1a0c8.j-schroeder@myrealbox.com> Message-ID: On Fri, 14 Dec 2001, Jacob Schroeder wrote: > Donald Becker wrote: > > On Fri, 14 Dec 2001, Jacob Schroeder wrote: > > > The hub is a repeater (a somewhat old 10Mbps Linksys with 8 RJ-45 > > > ports and 1 BNC). ifconfig for this NIC currently shows 382,699 RX > > > packets, 993,522 TX packets and 232,851 collisions with 0 receive or > > > transmit errors. > > > > These might be reasonable numbers for a busy network on a 10Mbps > > repeater. Just check /proc/net/dev (not 'ifconfig' or 'netstat -i') to > > verify that you don't have errors. > /proc/net/dev reports no errors for eth0. > With 5 computers hooked up to the network but none talking, I can get > a little over 150 collisions just doing 10 pings to another Linux > machine. So that's why I was a little concerned, but from what I'm > hearing I guess that's not too abnormal. That is abnormal. The maximum non-error collision count is 15 collisions per packet. It's very unlikely that a packet will get to 15 collisions, so if you are actually seeing 150 with 10 packets, something is wrong with the counts. > I'm not sure I'll be able to upgrade to the 0.93 driver for a while, I > don't want to bother this list with my trivial problems of not being > able to successfully compile them. I've done the kernel on numerous > occasions, and read all the documentation for tulip, but I'm still not > successful. Use the suggestions in http://www.scyld.com/network/updates.html I think that most possible problems have been addressed in the archives, but there are many possible ways for a distribution to mess around with the header files and paths. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri Dec 14 18:02:01 2001 From: becker@scyld.com (Donald Becker) Date: Fri Dec 14 18:02:01 2001 Subject: [tulip] W-LINX LinxPRO Ethernet In-Reply-To: <20011214230550.A3344@physik.tu-muenchen.de> Message-ID: On Fri, 14 Dec 2001, Michael Thaler wrote: > On Fri, Dec 14, 2001 at 05:08:35PM -0500, Donald Becker wrote: > > > > tulip.c:v0.91g-ppc 7/16/99 becker@scyld.com (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) > > > eth0: Digital DS21143 Tulip rev 17 at 0x800, EEPROM not present, 00:4C:69:6E:75:79, IRQ 9. > > > > Hmmm, the driver was not able to read the EEPROM. > > > > > eth0: MII transceiver #1 config 3000 status 7849 advertising 01e1. > > > eth0: 21143 10mbps sensed media. > > > eth0: 21143 10baseT link beat good. > > > > Hmmm, my driver releases should only use the MII transceiver if one is > > found. I suspect one of the modifications changed the behavior, in this > > case breaking the driver. Keep in mind, though, that the primary problem > > is reading the EEPROM, not the fall-back media selection. > > Is there any chance to get the card working or it is better to just > bring the card back and get another one? Run 'tulip-diag -ee' to see if the EEPROM can be read. http://www.scyld.com/diag/index.html As usual, I suggest using v0.93 rather than the much-modified 0.91-ppc. > Will it help to look for the resources the Win2000 driver > uses? No. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From joker@netswarm.net Sat Dec 15 09:42:01 2001 From: joker@netswarm.net (Christian Birchinger) Date: Sat Dec 15 09:42:01 2001 Subject: [tulip] ANA-6944A/TX and Linux 2.4.16 kernel Message-ID: <20011215154113.A929@netswarm.net> Hello... I have an ANA-6944A/TX card which works great with the latest driver (tulip.c:v0.93 11/7/2001) on my linux 2.4.16 system. With the builtin tulip driver from 2.4.16 it locks the whole machine when 2 or more interfaces are configured (ifconfig ethX x.x.x.x) at the same time. The devel driver from sourceforge (1.1.8) behaves exactly the same. I had to build the driver as module since the tulip files are totaly different in the 2.4 kerneltree. Due to lack of knowledge of the kernel and it's makefiles i was not able to staticaly build the driver into the kernel. Did anyone here build the "tulip.c:v0.93 11/7/2001"-driver into a 2.4 kernel it and can provide me information how to do this? The update.html mentions that it's experimental with 2.4. However i would like to experiment :) -- Christian Birchinger From marinho@exatas.unisinos.br Mon Dec 17 11:32:01 2001 From: marinho@exatas.unisinos.br (Marinho Barcellos) Date: Mon Dec 17 11:32:01 2001 Subject: [tulip] SIOCGMIIPHY Message-ID: <3C1E1BA0.D118CA6B@exatas.unisinos.br> Hello anyone has any idea why a configuration operation (ioctl()) SIOCGMIIPHY on a socket might fail, considering it's a Conexant board and as such has a MII transceiver? (Info: kernel 2.4.8, driver tulip.c:v0.93 11/7/2001) Error message: [root@tyne diag]# mii-diag -vw eth0 mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html SIOCGMIIPHY on eth0 failed: Operation not supported The above happens in the following section of code in mii-diag: /* Get the vitals from the interface. */ strncpy(ifr.ifr_name, ifname, IFNAMSIZ); if (ioctl(skfd, SIOCGMIIPHY, &ifr) < 0) { fprintf(stderr, "SIOCGMIIPHY on %s failed: %s\n", ifname, strerror(errno)); (void) close(skfd); return 1; } Many thanks, Marinho. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= Prof. Marinho Barcellos marinho@exatas.unisinos.br PIP/CA - Centro 6 http://www.inf.unisinos.br/~marinho/ UNISINOS - Universidade do Vale do Rio dos Sinos Av. Unisinos, 950 Phone: (051) 590-3333 ext.1639 Sao Leopoldo, RS, Brazil CEP 93022-000 FAX 5908162 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-= From mjs@bigfoot.com Mon Dec 17 12:26:01 2001 From: mjs@bigfoot.com (Matthew J. Secaur) Date: Mon Dec 17 12:26:01 2001 Subject: [tulip] Tulip driver fails to autonegotiate correctly Message-ID: <20011217111221.A6070@ea.2y.net> Hello, all! I am running box at home with SuSE Linux 7.3. The network is a 10BaseT-HD with a cheap hub. When loading the tulip module with no options, I fail to get a link light. tulip-diag shows that the card is set to 100BaseT, which is obviously not right. The only way (of which I am aware) to force the tulip driver to use 10BaseT is by using options=4, which forces it to 10BaseT-FD. So I get connectivity, but since the duplex is wrong, I only get about 8KB per second with a lot of collisions. Is there a way to force 10BaseT-HD in the driver? If not, how can I get the driver to correctly autonegotiate the line speed and duplex? I purchased a cheap PCI network card this weekend and it seems to work just fine with autonegotiation on the same hub (but a different driver for the card). Any help or input is appreciated! --Matt-- From becker@scyld.com Mon Dec 17 12:46:01 2001 From: becker@scyld.com (Donald Becker) Date: Mon Dec 17 12:46:01 2001 Subject: [tulip] Re: SIOCGMIIPHY In-Reply-To: <3C1E1BA0.D118CA6B@exatas.unisinos.br> Message-ID: On Mon, 17 Dec 2001, Marinho Barcellos wrote: > anyone has any idea why a configuration operation (ioctl()) > SIOCGMIIPHY on a socket might fail, considering it's a > Conexant board and as such has a MII transceiver? > (Info: kernel 2.4.8, driver tulip.c:v0.93 11/7/2001) Yes. Someone changed the numerical value associated with 'SIOCGMIIPHY'. This was a serious, silent change to the API. If you want a new value, change the name. > Error message: > [root@tyne diag]# mii-diag -vw eth0 > mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > SIOCGMIIPHY on eth0 failed: Operation not supported mii-diag v2.03 now tries both possible values for 'SIOCGMIIPHY', and I'm slowly converting the drivers to use both of the numeric values e.g. case 0x8947: case 0x89F0: /* SIOCGMIIPHY */ This is a very frustrating interface change. I don't know if I should ascribe it to incompetence or malice. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Mon Dec 17 14:00:01 2001 From: becker@scyld.com (Donald Becker) Date: Mon Dec 17 14:00:01 2001 Subject: [tulip] Tulip driver fails to autonegotiate correctly In-Reply-To: <20011217111221.A6070@ea.2y.net> Message-ID: On Mon, 17 Dec 2001, Matthew J. Secaur wrote: > I am running box at home with SuSE Linux 7.3. The network is a > 10BaseT-HD with a cheap hub. When loading the tulip module with no > options, I fail to get a link light. tulip-diag shows that the card > is set to 100BaseT, which is obviously not right. The only way (of > which I am aware) to force the tulip driver to use 10BaseT is by using > options=4, which forces it to 10BaseT-FD. So I get connectivity, but > since the duplex is wrong, I only get about 8KB per second with a lot > of collisions. What driver version are you using? What is the chip? What is the detection message? > Is there a way to force 10BaseT-HD in the driver? Yes. See http://www.scyld.com/network/tulip.html If not, how > I purchased a cheap PCI network card this weekend and it seems to work > just fine with autonegotiation on the same hub (but a different driver > for the card). The Tulip driver should properly use autonegotiation on all but 21140 cards using SYM transceivers. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From j-schroeder@myrealbox.com Mon Dec 17 14:34:01 2001 From: j-schroeder@myrealbox.com (Jacob Schroeder) Date: Mon Dec 17 14:34:01 2001 Subject: [tulip] LNE100TX rev. 5.0 In-Reply-To: References: <20011214163343.44f1a0c8.j-schroeder@myrealbox.com> Message-ID: <20011217133423.4c214dfe.j-schroeder@myrealbox.com> On Fri, 14 Dec 2001 18:08:05 -0500 (EST) Donald Becker wrote: > On Fri, 14 Dec 2001, Jacob Schroeder wrote: > > > Donald Becker wrote: > > > On Fri, 14 Dec 2001, Jacob Schroeder wrote: > > > > The hub is a repeater (a somewhat old 10Mbps Linksys with 8 RJ-45 > > > > ports and 1 BNC). ifconfig for this NIC currently shows 382,699 RX > > > > packets, 993,522 TX packets and 232,851 collisions with 0 receive or > > > > transmit errors. > > > > > > These might be reasonable numbers for a busy network on a 10Mbps > > > repeater. Just check /proc/net/dev (not 'ifconfig' or 'netstat -i') to > > > verify that you don't have errors. > > /proc/net/dev reports no errors for eth0. > > > With 5 computers hooked up to the network but none talking, I can get > > a little over 150 collisions just doing 10 pings to another Linux > > machine. So that's why I was a little concerned, but from what I'm > > hearing I guess that's not too abnormal. > > That is abnormal. The maximum non-error collision count is 15 > collisions per packet. It's very unlikely that a packet will get to 15 > collisions, so if you are actually seeing 150 with 10 packets, something > is wrong with the counts. > > > I'm not sure I'll be able to upgrade to the 0.93 driver for a while, I > > don't want to bother this list with my trivial problems of not being > > able to successfully compile them. I've done the kernel on numerous > > occasions, and read all the documentation for tulip, but I'm still not > > successful. > > Use the suggestions in > http://www.scyld.com/network/updates.html > > I think that most possible problems have been addressed in the archives, > but there are many possible ways for a distribution to mess around with > the header files and paths. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > Well, I'm been doing some working with it today, and I can't duplicate the problem. I must've left an ssh connection open or something when I saw those 150 collisions, in which case I should've paid better attention to the number of TX and RX packets. With only two computers talking today I can't get it to do more than an average of 1 collision per every 4 TX packets, and that doesn't count the number of RX packets either. Oh, well. I'm just glad that it doesn't seem to be causing any errors and my speed's not that bad for a 10Mbps network. I'll let you know the results if I'm able to use the 0.93 driver. I'm still fighting with the driver in Debian trying to figure out why parts of the kernel source don't seem to be in the right place for the compile instructions to work (I've tried all the web pages on www.scyld.com and the compile instructions listed at the end of the source file). Thanks again for your help and excellent work, Jacob ----- Windows: 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. Linux: The ultimate windows patch. http://www.linux.org/ From jasher1@tampabay.rr.com Mon Dec 17 15:08:01 2001 From: jasher1@tampabay.rr.com (Jesse W. Asher) Date: Mon Dec 17 15:08:01 2001 Subject: [tulip] Problems getting tulip to work with Linksys. Message-ID: <3C1E5082.71B090F0@tampabay.rr.com> --------------D0F15AF9CE800D143EE28514 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm having some problems with getting the tulip driver installed and running with following configuration: * Latest tulip driver * Toshiba Tecra 8100 * Linksys EtherFast 10/100 CardBus PC Card * Stock 2.4.16 kernel running on RedHat 7.1 When I do a "depmod -ae", I get the following error messages: [root@wayfarer tulip]# depmod -ae depmod: *** Unresolved symbols in /lib/modules/2.4.16/kernel/drivers/net/tulip/tulip.o depmod: release_region_R43bde9b1 depmod: eth_type_trans_R02771567 depmod: pci_write_config_dword_Rf0fbd200 depmod: pci_read_config_byte_Re5ceea13 depmod: skb_over_panic_R4f682074 depmod: init_etherdev_R3808c591 depmod: eth_copy_and_sum_R394509df depmod: add_timer_Rbea990b2 depmod: __kfree_skb_Rbc8c3f46 depmod: bh_active_Rfff9d0a3 depmod: alloc_skb_Rb134d5f4 depmod: unregister_netdev_Re24126b3 depmod: dev_close_R168821ba depmod: request_region_R6d32b2d7 depmod: netif_rx_R0a3fcdc4 depmod: del_timer_R5811f067 depmod: *** Unresolved symbols in /lib/modules/2.4.16/pcmcia/cb_shim.o depmod: pcibios_read_config_byte depmod: kmalloc depmod: pcibios_read_config_dword depmod: __ioremap depmod: kfree depmod: unregister_driver depmod: pci_find_slot depmod: register_driver depmod: pcibios_read_config_word depmod: printk depmod: *** Unresolved symbols in /lib/modules/2.4.16/pcmcia/pci-scan.o depmod: pci_write_config_byte depmod: kmalloc depmod: pci_find_class depmod: __check_region depmod: pci_read_config_byte depmod: pci_read_config_dword depmod: __ioremap depmod: pci_read_config_word depmod: kfree depmod: pci_set_master depmod: pci_write_config_dword depmod: pci_write_config_word depmod: printk depmod: ioport_resource depmod: *** Unresolved symbols in /lib/modules/2.4.16/pcmcia/tulip_cb.o depmod: eth_type_trans depmod: __kfree_skb depmod: alloc_skb depmod: init_etherdev depmod: __release_region depmod: kmalloc depmod: pci_read_config_byte depmod: cpu_raise_softirq depmod: free_irq depmod: unregister_netdev depmod: pci_read_config_dword depmod: iounmap depmod: __ioremap depmod: del_timer depmod: kfree depmod: unregister_driver depmod: pci_find_slot depmod: request_irq depmod: netif_rx depmod: skb_over_panic depmod: dev_close depmod: pci_write_config_dword depmod: register_driver depmod: jiffies depmod: softnet_data depmod: __request_region depmod: printk depmod: add_timer depmod: ioport_resource I've compiled the cb_shim.c, pci_scan.c, and tulip.c and put them into /lib/modules/2.4.16/pcmcia. Any help would be appreciated!! -- Jesse W. Asher jasher1@tampabay.rr.com --------------D0F15AF9CE800D143EE28514 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I'm having some problems with getting the tulip driver installed and running with following configuration:

* Latest tulip driver
* Toshiba Tecra 8100
* Linksys EtherFast 10/100 CardBus PC Card
* Stock 2.4.16 kernel running on RedHat 7.1

When I do a "depmod -ae", I get the following error messages:

[root@wayfarer tulip]# depmod -ae
depmod: *** Unresolved symbols in /lib/modules/2.4.16/kernel/drivers/net/tulip/tulip.o
depmod:       release_region_R43bde9b1
depmod:       eth_type_trans_R02771567
depmod:       pci_write_config_dword_Rf0fbd200
depmod:       pci_read_config_byte_Re5ceea13
depmod:       skb_over_panic_R4f682074
depmod:       init_etherdev_R3808c591
depmod:       eth_copy_and_sum_R394509df
depmod:       add_timer_Rbea990b2
depmod:       __kfree_skb_Rbc8c3f46
depmod:       bh_active_Rfff9d0a3
depmod:       alloc_skb_Rb134d5f4
depmod:       unregister_netdev_Re24126b3
depmod:       dev_close_R168821ba
depmod:       request_region_R6d32b2d7
depmod:       netif_rx_R0a3fcdc4
depmod:       del_timer_R5811f067
depmod: *** Unresolved symbols in /lib/modules/2.4.16/pcmcia/cb_shim.o
depmod:       pcibios_read_config_byte
depmod:       kmalloc
depmod:       pcibios_read_config_dword
depmod:       __ioremap
depmod:       kfree
depmod:       unregister_driver
depmod:       pci_find_slot
depmod:       register_driver
depmod:       pcibios_read_config_word
depmod:       printk
depmod: *** Unresolved symbols in /lib/modules/2.4.16/pcmcia/pci-scan.o
depmod:       pci_write_config_byte
depmod:       kmalloc
depmod:       pci_find_class
depmod:       __check_region
depmod:       pci_read_config_byte
depmod:       pci_read_config_dword
depmod:       __ioremap
depmod:       pci_read_config_word
depmod:       kfree
depmod:       pci_set_master
depmod:       pci_write_config_dword
depmod:       pci_write_config_word
depmod:       printk
depmod:       ioport_resource
depmod: *** Unresolved symbols in /lib/modules/2.4.16/pcmcia/tulip_cb.o
depmod:       eth_type_trans
depmod:       __kfree_skb
depmod:       alloc_skb
depmod:       init_etherdev
depmod:       __release_region
depmod:       kmalloc
depmod:       pci_read_config_byte
depmod:       cpu_raise_softirq
depmod:       free_irq
depmod:       unregister_netdev
depmod:       pci_read_config_dword
depmod:       iounmap
depmod:       __ioremap
depmod:       del_timer
depmod:       kfree
depmod:       unregister_driver
depmod:       pci_find_slot
depmod:       request_irq
depmod:       netif_rx
depmod:       skb_over_panic
depmod:       dev_close
depmod:       pci_write_config_dword
depmod:       register_driver
depmod:       jiffies
depmod:       softnet_data
depmod:       __request_region
depmod:       printk
depmod:       add_timer
depmod:       ioport_resource

I've compiled the cb_shim.c, pci_scan.c, and tulip.c and put them into /lib/modules/2.4.16/pcmcia.  Any help would be appreciated!! 

-- 
Jesse W. Asher              jasher1@tampabay.rr.com
  --------------D0F15AF9CE800D143EE28514-- From kenthunt@yahoo.com Tue Dec 18 00:26:01 2001 From: kenthunt@yahoo.com (Kent Hunt) Date: Tue Dec 18 00:26:01 2001 Subject: [tulip] Re: SIOCGMIIPHY (and SIOCGMIIREG) In-Reply-To: Message-ID: <20011218052528.10439.qmail@web14507.mail.yahoo.com> My two cents. I finally was able to get mii-diag working for my LanFinity Conexant on presario 1700. In addition to what Donald has below, I had to add to the tulip.c (v0.93) driver a similar workaround for SIOCGMIIREG case 0x8948: case 0x89F1: /* SIOCGMIIREG */ And here's my mii-diag output. Basic registers of MII PHY #1: 1000 782d 0022 1720 01e1 45e1 0007 2001. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT- FD 10baseT, w/ 802.3X flow control. End of basic transceiver informaion. Kent PS. What should we do to fix the incorrect statistics for TX line in ifconfig? --- Donald Becker wrote: > On Mon, 17 Dec 2001, Marinho Barcellos wrote: > > > anyone has any idea why a configuration operation > (ioctl()) > > SIOCGMIIPHY on a socket might fail, considering > it's a > > Conexant board and as such has a MII transceiver? > > (Info: kernel 2.4.8, driver tulip.c:v0.93 > 11/7/2001) > > Yes. Someone changed the numerical value associated > with 'SIOCGMIIPHY'. > This was a serious, silent change to the API. If > you want a new value, > change the name. > > > Error message: > > [root@tyne diag]# mii-diag -vw eth0 > > mii-diag.c:v2.00 4/19/2000 Donald Becker > (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > SIOCGMIIPHY on eth0 failed: Operation not > supported > > mii-diag v2.03 now tries both possible values for > 'SIOCGMIIPHY', and > I'm slowly converting the drivers to use both of the > numeric values e.g. > > case 0x8947: case 0x89F0: /* SIOCGMIIPHY */ > > This is a very frustrating interface change. I > don't know if I should > ascribe it to incompetence or malice. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf > Clusters > Annapolis MD 21403 410-990-9993 > > _______________________________________________ > tulip mailing list, tulip@scyld.com > To change to digest mode or unsubscribe visit > http://www.scyld.com/mailman/listinfo/tulip __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From wwh20610@cmsu2.cmsu.edu Tue Dec 18 01:17:01 2001 From: wwh20610@cmsu2.cmsu.edu (William Harrington) Date: Tue Dec 18 01:17:01 2001 Subject: [tulip] ANA 6944A/TX weird after testing it with win2k and then going back to Linux Message-ID: <001e01c1878b$c32f85c0$facb5b99@darksrvr> This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C18759.769945C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Having a bit of a problem here. The card was in the same slot, no = configuration differences, probably the only thing that changed was the = IRQ's the interfaces were using. Before I was goofing around with = win2k, I had a successful installation of slackware with 2.4.16 kernel = using the de4x5.o module for the DEC 21140, and I had 4 3c905c's along = with it (each running their own subnets). I installed win2k and it = ended up seeing it as an intel 21140 of course wasn't working, nothing = was working..... now when I go back to Linux, the card isn't working = right. Now either something was changed on the card itself, which I = suspect, or something else is happening. When I insmod de4x5 this is = what is in the message console: eth0: DC21140 at 0xd000 (PCI bus 2, device 4), h/w address = 00:00:d1:1e:7a:54, and requires IRQ10 (provided by PCI BIOS). de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com eth1: DC21140 at 0xd000 (PCI bus 2, device 5), h/w address = 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI BIOS). de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com eth2: DC21140 at 0xd000 (PCI bus 2, device 6), h/w address = 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI BIOS). de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com eth3: DC21140 at 0xd000 (PCI bus 2, device 7), h/w address = 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI BIOS). de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com I can run dhcpcd on eth0 and get an ip and get out onto the net just = fine. If I do dhcpcd on either of the other interfaces I get nothing. = I can't figure out why the last 3 interfaces are getting the same h/w = address. It is baffling me. Maybe I"m missing something I should have = in the kernel, but I don't think so. Is there something I need to write = to the ANA-6944A/TX to get the eeprom back to where it should be. When = I use the tulip.o I each interface gets a different h/w address, but I = can't use dhcpcd to get ip's on the last 3 as well. Here is the tulip = information: Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) = block. tulip0: MII transceiver #1 config 3100 status 7849 advertising 0101. tulip0: Advertising 01e1 on PHY 1, previously advertising 0101. eth0: Digital DS21140 Tulip rev 34 at 0xd000, 00:00:D1:1E:7A:54, IRQ 10. tulip1: Controller 1 of multiport board. tulip1: EEPROM default media type Autosense. tulip1: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) = block. tulip1: MII transceiver #1 config 3100 status 7849 advertising 0101. tulip1: Advertising 01e1 on PHY 1, previously advertising 0101. eth1: Digital DS21140 Tulip rev 34 at 0xd400, EEPROM not present, = 00:00:D1:1E:7A:55, IRQ 10. tulip2: Controller 2 of multiport board. tulip2: EEPROM default media type Autosense. tulip2: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) = block. tulip2: MII transceiver #1 config 3100 status 7849 advertising 0101. tulip2: Advertising 01e1 on PHY 1, previously advertising 0101. eth2: Digital DS21140 Tulip rev 34 at 0xd800, EEPROM not present, = 00:00:D1:1E:7A:56, IRQ 10. tulip3: Controller 3 of multiport board. tulip3: EEPROM default media type Autosense. tulip3: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) = block. tulip3: MII transceiver #1 config 3100 status 7849 advertising 0101. tulip3: Advertising 01e1 on PHY 1, previously advertising 0101. eth3: Digital DS21140 Tulip rev 34 at 0xdc00, EEPROM not present, = 00:00:D1:1E:7A:57, IRQ 10. Not sure what is happening but it is definitely weird after win2k. Also = on bootup the bios shows the interfaces not all being on IRQ 10, like = the de4x5 and tulip are showing. They each have their own irq. Any = ideas anyone ? I'm not passing any parameters to the board as well. = The board is an ECS p6ba-a+ with an award bios. William ------=_NextPart_000_001B_01C18759.769945C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
   Having a bit of a problem = here. =20 The card was in the same slot, no configuration differences, probably = the only=20 thing that changed was the IRQ's the interfaces were using.  Before = I was=20 goofing around with win2k, I had a successful installation of slackware = with=20 2.4.16 kernel using the de4x5.o module for the DEC 21140, and I had 4 = 3c905c's=20 along with it (each running their own subnets).  I installed win2k = and it=20 ended up seeing it as an intel 21140 of course wasn't working, nothing = was=20 working..... now when I go back to Linux, the card isn't working = right. =20 Now either something was changed on the card itself, which I suspect, or = something else is happening.  When I insmod de4x5 this is what is = in the=20 message console:
 
eth0: DC21140 at 0xd000 (PCI bus 2, = device 4), h/w=20 address 00:00:d1:1e:7a:54, and requires IRQ10 (provided by PCI=20 BIOS).
de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com=
eth1: DC21140 at 0xd000 (PCI bus 2, = device 5), h/w=20 address 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI=20 BIOS).
de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com=
eth2: DC21140 at 0xd000 (PCI bus 2, = device 6), h/w=20 address 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI=20 BIOS).
de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com=
eth3: DC21140 at 0xd000 (PCI bus 2, = device 7), h/w=20 address 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI=20 BIOS).
de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com=
 
I can run dhcpcd on eth0 and get an ip = and get out=20 onto the net just fine.  If I do dhcpcd on either of the other = interfaces I=20 get nothing.  I can't figure out why the last 3 interfaces are = getting the=20 same h/w address.  It is baffling me.  Maybe I"m missing = something I=20 should have in the kernel, but I don't think so.  Is there = something I need=20 to write to the ANA-6944A/TX to get the eeprom back to where it should = be. =20 When I use the tulip.o I each interface gets a different h/w address, = but I=20 can't use dhcpcd to get ip's on the last 3 as well. Here is the tulip=20 information:
 

Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001)

tulip0: EEPROM default media type Autosense.

tulip0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1)=20 block.

tulip0: MII transceiver #1 config 3100 status 7849 advertising = 0101.

tulip0: Advertising 01e1 on PHY 1, previously advertising 0101.

eth0: Digital DS21140 Tulip rev 34 at 0xd000, 00:00:D1:1E:7A:54, IRQ = 10.

tulip1: Controller 1 of multiport board.

tulip1: EEPROM default media type Autosense.

tulip1: Index #0 - Media MII (#11) described by a 21140 MII PHY (1)=20 block.

tulip1: MII transceiver #1 config 3100 status 7849 advertising = 0101.

tulip1: Advertising 01e1 on PHY 1, previously advertising 0101.

eth1: Digital DS21140 Tulip rev 34 at 0xd400, EEPROM not present,=20 00:00:D1:1E:7A:55, IRQ 10.

tulip2: Controller 2 of multiport board.

tulip2: EEPROM default media type Autosense.

tulip2: Index #0 - Media MII (#11) described by a 21140 MII PHY (1)=20 block.

tulip2: MII transceiver #1 config 3100 status 7849 advertising = 0101.

tulip2: Advertising 01e1 on PHY 1, previously advertising 0101.

eth2: Digital DS21140 Tulip rev 34 at 0xd800, EEPROM not present,=20 00:00:D1:1E:7A:56, IRQ 10.

tulip3: Controller 3 of multiport board.

tulip3: EEPROM default media type Autosense.

tulip3: Index #0 - Media MII (#11) described by a 21140 MII PHY (1)=20 block.

tulip3: MII transceiver #1 config 3100 status 7849 advertising = 0101.

tulip3: Advertising 01e1 on PHY 1, previously advertising 0101.

eth3: Digital DS21140 Tulip rev 34 at 0xdc00, EEPROM not present,=20 00:00:D1:1E:7A:57, IRQ 10.

 

 

Not sure what is happening but it is definitely = weird after=20 win2k.  Also on bootup the bios shows the interfaces not all being = on IRQ=20 10, like the de4x5 and tulip are showing.  They each have their own = irq.  Any ideas anyone ?  I'm not passing any parameters to = the board=20 as well.  The board is an ECS p6ba-a+ with an award = bios.

 

William

------=_NextPart_000_001B_01C18759.769945C0-- From becker@scyld.com Tue Dec 18 01:35:01 2001 From: becker@scyld.com (Donald Becker) Date: Tue Dec 18 01:35:01 2001 Subject: [tulip] Re: SIOCGMIIPHY (and SIOCGMIIREG) In-Reply-To: <20011218052528.10439.qmail@web14507.mail.yahoo.com> Message-ID: On Mon, 17 Dec 2001, Kent Hunt wrote: > I finally was able to get mii-diag working for my > LanFinity Conexant on presario 1700. In addition to > what Donald has below, I had to add to the tulip.c > (v0.93) driver a similar workaround for SIOCGMIIREG > > case 0x8948: case 0x89F1: /* SIOCGMIIREG */ OK, thanks for the report. Summarizing for others: to force the media type with the 2.4 kernel you either need the updated mii-diag, or to make the following change to tulip.c Line 3058 - case SIOCGMIIPHY: /* Get the address of the PHY in use. */ + case 0x8947: case 0x89F0: + /* SIOCGMIIPHY: Get the address of the PHY in use. */ Line 3066 - case SIOCGMIIREG: /* Read the specified MII register. */ + case 0x8948: case 0x89F1: + /* SIOCGMIIREG: Read the specified MII register. */ Line 3099 - case SIOCSMIIREG: /* Write the specified MII register */ + case 0x8949: case 0x89F2: + /* SIOCSMIIREG: Write the specified MII register */ > PS. What should we do to fix the incorrect statistics > for TX line in ifconfig? That's a more difficult problem. I can't get the information from Conexant to configure the chip to correctly report the Tx status. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From erik@iks-jena.de Tue Dec 18 04:08:01 2001 From: erik@iks-jena.de (Erik Heinz) Date: Tue Dec 18 04:08:01 2001 Subject: [tulip] ANA-6944A/TX and Linux 2.4.16 kernel In-Reply-To: <20011215154113.A929@netswarm.net>; from joker@netswarm.net on Sat, Dec 15, 2001 at 03:41:13PM +0100 References: <20011215154113.A929@netswarm.net> Message-ID: <20011217091224.A832@iks-jena.de> On Sat, Dec 15, 2001 at 03:41:13PM +0100, Christian Birchinger wrote: > > With the builtin tulip driver from 2.4.16 it locks the whole > machine when 2 or more interfaces are configured > (ifconfig ethX x.x.x.x) at the same time. This is a known problem. It's origin is - as far as I understood - a wrong IRQ assignment in the BIOS. Up to Linux-2.2 the tulip driver has fixed this. In Linux-2.4 the PCI subsystem deals itself with this sort of problems. Obviously, this does not work with the ANA-6944A/TX yet and at the moment noone seems to be working on it. > Did anyone here build the "tulip.c:v0.93 11/7/2001"-driver into a 2.4 > kernel it and can provide me information how to do this? I did, but it will not help you. It's not the tulip driver's fault. Cheers, Erik -- | Erik Heinz, IKS GmbH Jena * erik@iks-jena.de * privat: erik@jena.thur.de | +---------------------------------------------------------------------------+ From joker@netswarm.net Tue Dec 18 04:51:01 2001 From: joker@netswarm.net (Christian Birchinger) Date: Tue Dec 18 04:51:01 2001 Subject: [tulip] ANA 6944A/TX weird after testing it with win2k and then going back to Linux In-Reply-To: <001e01c1878b$c32f85c0$facb5b99@darksrvr>; from wwh20610@cmsu2.cmsu.edu on Tue, Dec 18, 2001 at 12:18:05AM -0600 References: <001e01c1878b$c32f85c0$facb5b99@darksrvr> Message-ID: <20011218105010.A1984@netswarm.net> Hi, I have the same problem with the duplicated HWaddresses on my ANA-6944A/TX with the de4x5 driver from 2.4.16. Try the tulip driver from: ftp://ftp.scyld.com/pub/network/ Instructions how to use it are here: http://www.scyld.com/network/updates.html It's "Linux 2.4"-alike stable on my system (Worked one week without crashing so it must be good ;) It's the only driver which works for me correctly. With 2.4 the tulip driver locks the machine when 2 or more interfaces are being configured and the de4x5 has duplicated HWaddresses. Theres some pci_reverse scan patch. But that patch only gives eth3 the HWaddress of eth0 and has dupplicated addresses for eth0-2. (It "reverses" the problem) On Tue, Dec 18, 2001 at 12:18:05AM -0600, William Harrington wrote: > Hello, > > Having a bit of a problem here. The card was in the same slot, no configuration differences, probably the only thing that changed was the IRQ's the interfaces were using. Before I was goofing around with win2k, I had a successful installation of slackware with 2.4.16 kernel using the de4x5.o module for the DEC 21140, and I had 4 3c905c's along with it (each running their own subnets). I installed win2k and it ended up seeing it as an intel 21140 of course wasn't working, nothing was working..... now when I go back to Linux, the card isn't working right. Now either something was changed on the card itself, which I suspect, or something else is happening. When I insmod de4x5 this is what is in the message console: > > eth0: DC21140 at 0xd000 (PCI bus 2, device 4), h/w address 00:00:d1:1e:7a:54, and requires IRQ10 (provided by PCI BIOS). > de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com > eth1: DC21140 at 0xd000 (PCI bus 2, device 5), h/w address 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI BIOS). > de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com > eth2: DC21140 at 0xd000 (PCI bus 2, device 6), h/w address 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI BIOS). > de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com > eth3: DC21140 at 0xd000 (PCI bus 2, device 7), h/w address 00:00:d1:1e:7a:55, and requires IRQ10 (provided by PCI BIOS). > de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com From gustavo@liveware.com.br Tue Dec 18 05:25:01 2001 From: gustavo@liveware.com.br (Luiz Gustavo Cunha Barbato) Date: Tue Dec 18 05:25:01 2001 Subject: [tulip] Compaq 10_100 MiniPCI Ethernet NIC Message-ID: <001901c187ae$43357280$5102010a@comp2> Hi, Can someone help me? I have a notebook Compaq Presario 1700 17XL460, with Compaq 10_100 MiniPCI Ethernet NIC ethernet interface , and Im trying to install the tulip driver(Ive downlowded this driver http://prdownloads.sourceforge.net/tulip/tulip-0.9.14.tar.gz), and I am using Conectiva Linux 7(or RedHat 7.2) with kernel 2.4.13. But I dont down how to install this driver. I try to do 'insmod tulip' but a error message appear saying (Hint: insmod erros can be caused by incorrect modules parameters, including invalid IO or IRQ parameters), but the tulip-diag detects my interface( Found a Conexant LANfinity adapter at 0x1400). Can someone help me? From alvin@iplink.net Tue Dec 18 11:08:01 2001 From: alvin@iplink.net (alvin) Date: Tue Dec 18 11:08:01 2001 Subject: [tulip] autonegotation problems with 21143 Message-ID: <3C1F69A5.26777591@iplink.net> I am running a UP1100 with an integrated 21142/3 NIC. I seem to be having some problems with autonegoation. The kernel is a more or less stock RH 2.2.19-6.2.1 the following is from my dmesg listing. eth0: Digital DS21143 Tulip rev 65 at 0x10100, 00:00:F0:51:00:EB, IRQ 5. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. eth0: Restarting 21143 autonegotiation, 0003ffff. eth0: tulip_open() irq 5. eth0: Restarting 21143 autonegotiation, 0003ffff. eth0: Done tulip_open(), CSR0 f8a0e000, CSR5 f0670004 CSR6 b2422202. eth0: 21143 link status interrupt 45e1d0ce, CSR5 f0268010, fffbffff. eth0: Switching to 100baseTx-FD based on link negotiation 01e0 & 45e1 = 01e0. eth0: 21143 non-MII 100baseTx-FD transceiver control 08af/0005. eth0: Setting CSR15 to 08af0008/00050008. eth0: Using media type 100baseTx-FD, CSR12 is ce. eth0: Setting CSR6 83860200/b3862202 CSR12 45e1d0ce. eth0: Transmit error, Tx status 7fffbc85. eth0: Transmit error, Tx status 7fffbc84. eth0: Transmit error, Tx status 7fffbc84. eth0: 21143 link status interrupt 45e1d2cc, CSR5 f8668000, fffbffff. eth0: 21143 100baseTx-FD link beat good. eth0: Transmit error, Tx status 7fffb080. eth0: Transmit error, Tx status 7fffb200. eth0: Transmit error, Tx status 7fffb200. eth0: Transmit error, Tx status 7fffb200. eth0: Transmit error, Tx status 7fffb200. eth0: Transmit error, Tx status 7fffb200. eth0: 21143 negotiation status 45e1d2cc, 100baseTx-FD. eth0: Using NWay-set 100baseTx-FD media, csr12 45e1d2cc. eth0: Transmit error, Tx status 7fffb200. If I let the driver autonegotate I get a large number of transmit errors. If I set the options=5 and try to force 100MB-FDX then I get the following recieve errors eth0: 21143 negotiation status 000002c0, 100baseTx-FD. eth0: Receive error, Rx status 00468326. eth0: Receive error, Rx status 004a8322. eth0: Receive error, Rx status 004c8326. eth0: Receive error, Rx status 00568326. eth0: Receive error, Rx status 004a8326. eth0: Receive error, Rx status 004c8322. eth0: Receive error, Rx status 00428322. eth0: Receive error, Rx status 005b8326. Any pointers or suggestions would be greatly appreciated. -- Alvin Starr || voice: (416)785-4051 Interlink Connectivity || fax: (416)785-3668 alvin@iplink.net || From becker@scyld.com Tue Dec 18 13:40:01 2001 From: becker@scyld.com (Donald Becker) Date: Tue Dec 18 13:40:01 2001 Subject: [tulip] autonegotation problems with 21143 In-Reply-To: <3C1F69A5.26777591@iplink.net> Message-ID: On Tue, 18 Dec 2001, alvin wrote: > I am running a UP1100 with an integrated 21142/3 NIC. > > I seem to be having some problems with autonegoation. The kernel is a > more or less stock RH 2.2.19-6.2.1 What driver version? > eth0: Using media type 100baseTx-FD, CSR12 is ce. > eth0: Setting CSR6 83860200/b3862202 CSR12 45e1d0ce. > eth0: Transmit error, Tx status 7fffbc85. This indicates a carrier error. The transceiver is not properly configured. I'm pretty certain that you are not using the v0.93 driver... > If I let the driver autonegotate I get a large number of transmit > errors. If I set the options=5 and try to force 100MB-FDX then I get the > following recieve errors Forcing 100baseTX-FDX turns off autonegotiation, thus your link partner is defaulting to half duplex. You are seeing corrupted Rx packets as the link partner stops transmitting due to the collision. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From tsombakos_mark@emc.com Tue Dec 18 15:24:00 2001 From: tsombakos_mark@emc.com (tsombakos, mark) Date: Tue Dec 18 15:24:00 2001 Subject: [tulip] Tulip and ANA6911A/TX Message-ID: In order to fix this, I'd like to replace the tulip driver found in RedHat and replace it with Donald's version. Does anyone have the magical changes for the makefile in kernel/drivers/net/tulip that will build tulip.o (with pci-scan.*)? I'm not very good at 'make' apparently :) Mark On Thu, 6 Dec 2001, tsombakos, mark wrote: > I'm having problems with the tulip driver included in > RedHat 7.2. My first issue is, I can't tell what version > is the "latest" tulip driver. 0.92-pre3(?) was 7.2's, > we bumped up to 0.92-pre6 (dated Nov 3) with a new kernel. > But on Sourceforge, it's up to 1.1.8, dated June 16, 2001... The most recent version from the original source tree is v0.93. Incremental releases have a version such as "0.93a" http://www.scyld.com/network/tulip.html ftp://www.scyld.com/pub/network/tulip.c The version in the kernel is a split from my releases, and has three dotted numbers as the version string. From gustavo@liveware.com.br Tue Dec 18 16:04:01 2001 From: gustavo@liveware.com.br (Luiz Gustavo Cunha Barbato) Date: Tue Dec 18 16:04:01 2001 Subject: [tulip] Compaq 10_100 MiniPCI Ethernet NIC References: <001901c187ae$43357280$5102010a@comp2> <000701c187f1$059985e0$280c0a0a@unimedia.net.mx> Message-ID: <000601c18807$90b56480$5102010a@comp2> Im using the 0.93 tulip driver and the 2.4.13 kernel. When I do: #!> insmod pci-scan.o <- OK but when I do: #!> insmod tulip.o Everything stop, keyboard, mouse .... and I need to reboot my Linux Box.; Why does it happen? Atenciosamente, Luiz Gustavo Cunha Barbato - Analista de Sistemas Trainee LIVEWARE, Tecnologia a Serviço Ltda - Tel/Fax: +55 35 3471 3210 gustavo@liveware.com.br - www.liveware.com.br ----- Original Message ----- From: Jorge E. Aparicio M. To: Luiz Gustavo Cunha Barbato Sent: Tuesday, December 18, 2001 4:22 PM Subject: Re: [tulip] Compaq 10_100 MiniPCI Ethernet NIC > Luiz, > > You should check the archive lists starting at July 2001. A lot of messages > have been posted about the topic since then... > > You should also check > http://user.cs.tu-berlin.de/~gregorrg/compaq/presario17xl470.html. This is > a great link for Presario 1700XL users. Section 9 (Network card) is a > summary of what you have to do to set the driver up. > > By the way, this message is being sent from a RH 7.1 linuxbox, kernel > 2.4.12, Compaq 10_100 MiniPCI Ethernet NIC, using Donald's drivers. > > Good luck, > > Jorge Aparicio. > > ----- Original Message ----- > From: "Luiz Gustavo Cunha Barbato" > To: > Sent: Tuesday, December 18, 2001 4:25 AM > Subject: [tulip] Compaq 10_100 MiniPCI Ethernet NIC > > > > Hi, Can someone help me? > > > > > > I have a notebook Compaq Presario 1700 17XL460, with Compaq 10_100 > > MiniPCI Ethernet NIC ethernet interface , and Im trying to install the > tulip > > driver(Ive downlowded this driver > > http://prdownloads.sourceforge.net/tulip/tulip-0.9.14.tar.gz), and I am > > using Conectiva Linux 7(or RedHat 7.2) with kernel 2.4.13. > > > > But I dont down how to install this driver. > > > > I try to do 'insmod tulip' but a error message appear saying (Hint: insmod > > erros can be caused by incorrect modules parameters, including invalid IO > or > > IRQ parameters), but the tulip-diag detects my interface( Found a Conexant > > LANfinity adapter at 0x1400). > > > > Can someone help me? > > > > > > > > _______________________________________________ > > tulip mailing list, tulip@scyld.com > > To change to digest mode or unsubscribe visit > > http://www.scyld.com/mailman/listinfo/tulip From Dave@keston.u-net.com Tue Dec 18 19:18:00 2001 From: Dave@keston.u-net.com (David Flynn) Date: Tue Dec 18 19:18:00 2001 Subject: [tulip] PCI reverse References: <001e01c1878b$c32f85c0$facb5b99@darksrvr> <20011218105010.A1984@netswarm.net> Message-ID: <002101c18822$d348e540$1901a8c0@node0.idium.eu.org> > I have the same problem with the duplicated HWaddresses on my > ANA-6944A/TX with the de4x5 driver from 2.4.16. > It's the only driver which works for me correctly. With 2.4 > the tulip driver locks the machine when 2 or more interfaces > are being configured and the de4x5 has duplicated HWaddresses. > Theres some pci_reverse scan patch. But that patch only > gives eth3 the HWaddress of eth0 and has dupplicated addresses > for eth0-2. (It "reverses" the problem) The pci_reverse patch is only a fix for machines with retarded BIOSes. The problem is caused by the BIOS looking at devices on the other side of a PCI bridge in the wrong order. Symptoms of this include, when the card is detected and configured by the driver, the first three ports will have an EEPROM not found error, and incorrect MAC addresses (by incorrect, i mean that it will look like this: Jan 1 00:00:25 firewall0 kernel: eth0: Digital DC21040 Tulip rev 36 at 0xfc80, EEPROM not present, 00:4C:69:6E:75:79, IRQ 11. Jan 1 00:00:25 firewall0 kernel: eth1: Digital DC21040 Tulip rev 36 at 0xfc00, EEPROM not present, 00:4C:69:6E:75:7A, IRQ 11. Jan 1 00:00:25 firewall0 kernel: eth2: Digital DC21040 Tulip rev 36 at 0xf880, EEPROM not present, 00:4C:69:6E:75:7B, IRQ 11. Jan 1 00:00:25 firewall0 kernel: eth3: Digital DC21040 Tulip rev 36 at 0xf800, 00:00:92:92:39:58, IRQ 3. if you think about 0x4C 0x69 0x6E 0x75 0x79 in ASCII, it spells LINUX, this is a BOGUS address that is coded into the tulip driver.) Now the fix for this is to reverse the order devices on the other side of a PCI bridge are put into a list in the kernel. that is all the patch does. This then allows the driver to detect the first port as it should do (the one with the EEPROM), and all will almost work. Note, the tulip driver attempts to fix the problem itself in 2.2.x kernels, and it is successfull. However, things changed in 2.4 and this no longer works. i will say it one more time, the patch only fixes problems with RETARDED BIOSES that have a slightly incorrect interpretation of the PCI (i think) specs. Now why i can not use the tulip driver (i last tried it when 2.4.5 was arround) i dont know. it just hangs the system when you try and bring two interfaces up. the de4x5 driver presents no such problem. I do not know why that happens, and since de4x5 fixes it, and this is an operational firewall, it isnt too easy to start playing arround with kernel code and crashing the box. although, if someone has some ideas i might beable to do some work during the night over christmas. Thanks, Dave From becker@scyld.com Tue Dec 18 19:45:01 2001 From: becker@scyld.com (Donald Becker) Date: Tue Dec 18 19:45:01 2001 Subject: [tulip] PCI reverse In-Reply-To: <002101c18822$d348e540$1901a8c0@node0.idium.eu.org> Message-ID: On Wed, 19 Dec 2001, David Flynn wrote: > The pci_reverse patch is only a fix for machines with retarded BIOSes. The > problem is caused by the BIOS looking at devices on the other side of a PCI > bridge in the wrong order. > > Symptoms of this include, when the card is detected and configured by the > driver, the first three ports will have an EEPROM not found error, and > incorrect MAC addresses (by incorrect, i mean that it will look like this: The v0.92/v0.93 driver will go back and correct the bogus driver-generated station addresses when it does find the EEPROM. But a bogus station address isn't a fatal problem -- it won't crash the machine. It's a bad IRQ assignment that is crashing the machine. > Now the fix for this is to reverse the order devices on the other side of a > PCI bridge are put into a list in the kernel. that is all the patch does. > This then allows the driver to detect the first port as it should do (the > one with the EEPROM), and all will almost work. Note, the tulip driver > attempts to fix the problem itself in 2.2.x kernels, and it is successfull. > However, things changed in 2.4 and this no longer works. The driver must also do one additional thing: it corrects a related x86 BIOS bug that assigns different IRQs behind the bus bridge, when the bus bridge actually puts all interrupts on a single IRQ. For this to correction to work the driver must identify the primary interface, which does get the correct IRQ assignment, and copy that IRQ to the other interfaces behind the bus bridge. The code at line 769 that does this is: #if defined(__i386__) /* Patch up x86 BIOS bug. */ if (last_irq) irq = last_irq; #endif } > i will say it one more time, the patch only fixes problems with RETARDED > BIOSES that have a slightly incorrect interpretation of the PCI (i think) > specs. Specifically, the fatl bug is BIOSes that only half understand bus bridges. Since everyone started out with the same PCI BIOS code, and very few PCI cards have bus bridges, the bug has remained unfixed for years. > Now why i can not use the tulip driver (i last tried it when 2.4.5 was > arround) i dont know. it just hangs the system when you try and bring two > interfaces up. It hang when there is an interrupt that the device drivers cannot clear. Note: The kernel could actually detect and report this case, but it would add some slight operational overhead. ("Hey, I've called these interrupt handlers 10000 times and the interrupt still isn't cleared.) Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jdcalus@attbi.com Tue Dec 18 21:25:01 2001 From: jdcalus@attbi.com (Jeff) Date: Tue Dec 18 21:25:01 2001 Subject: [tulip] LNE100TX RH 6.2 and unresolved symbols Message-ID: <1008728672.2221.2.camel@wookie> OKay I have read through every entry I could find in the mailing list and have searched other groups and on the web with google, still no luck. I am getting the following when trying to load the tulip module. Using /lib/modules/2.2.14-5.0/net/tulip.o /lib/modules/2.2.14-5.0/net/tulip.o: unresolved symbol __global_cli /lib/modules/2.2.14-5.0/net/tulip.o: unresolved symbol __global_save_flags /lib/modules/2.2.14-5.0/net/tulip.o: unresolved symbol __global_restore_flags I am using 0.93 of the tulip driver. I have compiled pci-scan.c and have the latest kern_compat.h and pci_scan.h includes. I used the following to compile: gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c tulip.c move the tulip.o file to /lib/modules/2.2.14-5.0/net/ dir. I noticed another posting indicating these errors are releated to SMP system.map file. I have an SMP motherboard, but am not using the SMP kernel, since I only have 1 cpu installed. Any help would be appreciated. Cheers -Jeff From wwh20610@cmsu2.cmsu.edu Wed Dec 19 02:52:01 2001 From: wwh20610@cmsu2.cmsu.edu (William Harrington) Date: Wed Dec 19 02:52:01 2001 Subject: [tulip] Compiling tulip.c in slackware Message-ID: <006a01c18862$2a2b7c30$0a010a0a@darksrvr> This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C1882F.DD716080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I've tried a few times to compile the tulip.c driver. I get a bunch = of problems with the .h files. I notice in the code: for example: #include =20 when it looks for kernel.h is it going to look for it in = /usr/src/linux/include/linux/ ? Probably what I need to know, does it matter where I compile the = drivers ? Maybe it requires me to use a different kernel to compile it = if the .h files are any different. Slackware 8.0 dist and 2.4.16 kernel. William ------=_NextPart_000_0067_01C1882F.DD716080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
   I've tried a few times to = compile the=20 tulip.c driver.  I get a bunch of problems with the .h files.  = I=20 notice in the code: for example:
 
#include = <linux/kernel.h> 
when it looks for kernel.h is it going = to look for=20 it in /usr/src/linux/include/linux/ ?
 
    Probably what I need = to know,=20 does it matter where I compile the drivers ? Maybe it requires me to use = a=20 different kernel to compile it if the .h files are any = different.
 
Slackware 8.0 dist and 2.4.16 = kernel.
 
William
------=_NextPart_000_0067_01C1882F.DD716080-- From tsombakos_mark@emc.com Wed Dec 19 17:30:01 2001 From: tsombakos_mark@emc.com (tsombakos, mark) Date: Wed Dec 19 17:30:01 2001 Subject: [tulip] RE: Tulip and ANA6911A/TX Message-ID: I answered my own question and replaced the RH tulip driver with Donald's. Sadly, I have exactly the same problem. Power cycle the box, no link light. Unload/reload module, link light lights. After power cycle: /var/log/messages: Dec 19 17:44:23 lnl0117 kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker Dec 19 17:44:23 lnl0117 kernel: http://www.scyld.com/network/tulip.html Dec 19 17:44:23 lnl0117 kernel: eth0: Digital DS21143-xD Tulip rev 65 at 0xe08b9000, 00:00:D1:1E:E1:9D, IRQ 9. Dec 19 17:44:23 lnl0117 kernel: eth0: EEPROM default media type Autosense. Dec 19 17:44:23 lnl0117 kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 19 17:44:23 lnl0117 kernel: eth0: ***WARNING***: No MII transceiver found! tulip-diag: tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x1400. Digital DS21143 Tulip chip registers at 0x1400: 0x00: f8a08000 ffffffff ffffffff 1e4f7000 1e4f7200 f4000102 b2420000 f3fe0000 0x40: e0000000 fff583ff ffffffff 00000000 000020c6 ffff0001 fff8ffbf 8ff4c008 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. The NWay status register is 000020c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1109, device 2a00. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:D1:1E:E1:9D. EEPROM transceiver/media description table. Leaf node at offset 40, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 23. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0000. 21143 MII reset sequence is 3 words: 0821 0001 0000. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. EEPROM contents (64 words): 0x00: 1109 2a00 0000 0000 0000 0000 0000 0000 0x08: 0001 0103 0000 1ed1 9de1 2800 0000 0000 0x10: 0000 0000 0000 0000 0800 9701 0003 2102 0x18: 0008 0300 0821 0001 0000 7800 01e0 5000 0x20: 1800 8c00 4102 0009 0705 0006 0821 0005 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 042a 6f35 ID block CRC 0x01 (vs. 0x01). Full contents CRC 0x6f35 (read as 0x6f35). MII PHY found at address 17, status 0x7849. MII PHY #17 transceiver registers: 3100 7849 2000 5c01 0101 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c71 0000 3000 a3b9 0080 8005 001b. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7849 ... 7849. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 08:00:17:--:--:--, model 0 rev. 1. Vendor/Part: National Semiconductor 83840A. I'm advertising 0101: 100baseTx-FD Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. Internal autonegotiation state is 'Ability detect'. -------------------------------------------------------------- After driver reload: Dec 19 17:58:39 lnl0117 kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker Dec 19 17:58:39 lnl0117 kernel: http://www.scyld.com/network/tulip.html Dec 19 17:58:39 lnl0117 kernel: eth0: Digital DS21143-xD Tulip rev 65 at 0xe08b9000, 00:00:D1:1E:E1:9D, IRQ 9. Dec 19 17:58:39 lnl0117 kernel: eth0: EEPROM default media type Autosense. Dec 19 17:58:39 lnl0117 kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 19 17:58:39 lnl0117 kernel: eth0: MII transceiver #1 config 3100 status 7849 advertising 0101. tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x1400. Digital DS21143 Tulip chip registers at 0x1400: 0x00: f8a08000 ffffffff ffffffff 1f27c800 1f27ca00 f0000102 b20e0000 f3fe0000 0x40: e0000000 fff583ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff6c000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1109, device 2a00. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:00:D1:1E:E1:9D. EEPROM transceiver/media description table. Leaf node at offset 40, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 23. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0000. 21143 MII reset sequence is 3 words: 0821 0001 0000. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. EEPROM contents (64 words): 0x00: 1109 2a00 0000 0000 0000 0000 0000 0000 0x08: 0001 0103 0000 1ed1 9de1 2800 0000 0000 0x10: 0000 0000 0000 0000 0800 9701 0003 2102 0x18: 0008 0300 0821 0001 0000 7800 01e0 5000 0x20: 1800 8c00 4102 0009 0705 0006 0821 0005 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 042a 6f35 ID block CRC 0x01 (vs. 0x01). Full contents CRC 0x6f35 (read as 0x6f35). MII PHY found at address 1, status 0x786d. MII PHY #1 transceiver registers: 3100 786d 2000 5c01 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c61 0000 3000 a3b9 0080 8505 001b. Basic mode control register 0x3100: 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 08:00:17:--:--:--, model 0 rev. 1. Vendor/Part: National Semiconductor 83840A. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. Internal autonegotiation state is 'Autonegotiation disabled'. Mark From wongsm@netvigator.com Wed Dec 19 21:36:01 2001 From: wongsm@netvigator.com (Stephen S M Wong) Date: Wed Dec 19 21:36:01 2001 Subject: [tulip] Tulip chips Message-ID: <3C214F67.7A58F48C@netvigator.com> Dear Tulipers, 1) What is the latest tulip chip? (21143?) 2) Is Intel now the owner of the tulip chip? Do you know if there is any new development on the tulip series (say a GE chip)? 3) Are there any multiport (2 to 4) tulip cards available in the market? What will be your next recommendation other than tulip chip (for multiport 100TX card)? 4) I find some surplus original Digital Equipment Corporation 21143 cards in local market, the price is very cheap (US$18), is it a good alternative to say 3Com 3c905C, or Intel 82559? Thanks in advance for your help. Stephen Wong. From becker@scyld.com Thu Dec 20 00:13:00 2001 From: becker@scyld.com (Donald Becker) Date: Thu Dec 20 00:13:00 2001 Subject: [tulip] Tulip chips In-Reply-To: <3C214F67.7A58F48C@netvigator.com> Message-ID: On Thu, 20 Dec 2001, Stephen S M Wong wrote: > 1) What is the latest tulip chip? (21143?) Several of the Tulip clones, with a new release every few months. > 2) Is Intel now the owner of the tulip chip? Do you know if there is > any new development on the tulip series (say a GE chip)? Intel actually announced they were EOLing the chip last year, but were compelled to extend its life. > 3) Are there any multiport (2 to 4) tulip cards available in the > market? What will be your next recommendation other than tulip chip > (for multiport 100TX card)? I haven't been paying attention lately. Check D-Link and Znyx > 4) I find some surplus original Digital Equipment Corporation 21143 > cards in local market, the price is very cheap (US$18), is it a good > alternative to say 3Com 3c905C, or Intel 82559? The Tulip is still better for multicast filtering. The 905C has the best IP checksum support. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Thu Dec 20 00:23:01 2001 From: becker@scyld.com (Donald Becker) Date: Thu Dec 20 00:23:01 2001 Subject: [tulip] RE: Tulip and ANA6911A/TX In-Reply-To: Message-ID: On Wed, 19 Dec 2001, tsombakos, mark wrote: > I answered my own question and replaced the RH tulip driver > with Donald's. Sadly, I have exactly the same problem. > Power cycle the box, no link light. Unload/reload module, > link light lights. > > After power cycle: > > /var/log/messages: > Dec 19 17:44:23 lnl0117 kernel: tulip.c:v0.93 11/7/2001 Written by Donald ... > Dec 19 17:44:23 lnl0117 kernel: eth0: Digital DS21143-xD Tulip rev 65 at > 0xe08b9000, 00:00:D1:1E:E1:9D, IRQ 9. ... > Dec 19 17:44:23 lnl0117 kernel: eth0: ***WARNING***: No MII transceiver > found! Hmmm, bad. The transceiver isn't responding. But it does with tulip-diag, and later > tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com) ... > Media MII, block type 3, length 23. > MII interface PHY 0 (media type 11). > 21143 MII initialization sequence is 2 words: 0821 0000. > 21143 MII reset sequence is 3 words: 0821 0001 0000. This design requires a transceiver reset. One flaw with the Tulip SROM specifications is that it doesn't specify timing. Some other cards add some delay by repeating the reset setting. This card doesn't. I suspect that a longer reset might allow the transceiver to be detected. > MII PHY found at address 17, status 0x7849. > MII PHY #17 transceiver registers: > 3100 7849 2000 5c01 0101 0000 0000 0000 Transceivers are searched for in order. This gives the transceiver a few hundred microseconds to recover from the reset. > After driver reload: ... everything works. > Dec 19 17:58:39 lnl0117 kernel: eth0: Index #0 - Media MII (#11) described > by a 21142 MII PHY (3) block. > Dec 19 17:58:39 lnl0117 kernel: eth0: MII transceiver #1 config 3100 status > 7849 advertising 0101. Errrkkk? At address #1? It was at address #17 before. I now suspect a floating address strap pin. This might be a sample defect on your specific board. Do you have another similar board? Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From greearb@candelatech.com Thu Dec 20 01:15:01 2001 From: greearb@candelatech.com (Ben Greear) Date: Thu Dec 20 01:15:01 2001 Subject: [tulip] Tulip chips References: Message-ID: <3C2181AF.7060104@candelatech.com> Donald Becker wrote: > On Thu, 20 Dec 2001, Stephen S M Wong wrote: >>3) Are there any multiport (2 to 4) tulip cards available in the >>market? What will be your next recommendation other than tulip chip >>(for multiport 100TX card)? >> > > I haven't been paying attention lately. Check D-Link and Znyx Dlinks have worked much better than the zynx for me. The zynx won't auto-negotiate up to 100bt-FD. Becker's new drivers may fix that, I'm not sure... I'm pretty sure the one in the 2.4 kernel will not, at least as of 2.4.1 -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From jzhu@tachyon.net Thu Dec 20 21:45:01 2001 From: jzhu@tachyon.net (James Zhu) Date: Thu Dec 20 21:45:01 2001 Subject: [tulip] Netgear PNIC Stops working after cable disconnect Message-ID: <019601c189c9$facf5c90$bd00c80a@tachyon.net> Well, I still have problems w/ Netgear FX310-TX cards using the latest tulip.c (v0.93). The card stops working after disconnecting and reconnecting the Ethernet cable. I know many other has experienced this problem in the past.... I have this problem w/ all tulip drivers from 2.2.14-19 kernel tree.... So I tried Don's v0.93. same symptoms. Before the unplug the cable. tulip-diag report the card is happy in 100BaseTX mode, Port selection is MII, full duplex. The recv is "idle", and transmit is "waiting to transmit". After unplugging then plugging the cable, tulip-diag reports the port selection is 10mpbs-serial, half duplex. Both xmit and recv are in "stopped" state. I couldn't get them to restart. I tried "-R", "-F many_types"... I don't have problem w/ tulip.c from 2.2.12 kernel tree, but that driver hangs after a long session of stress test. (ie. overnight).... for that I am looking for alternatives... but all new tulip driver I tried so far has this disconnect problem.... Am I the only one seeing this? Here is the output of tulip-diag -mm, when the driver hangs: =================================================== tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xe000. 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 160. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 1000 782d 0040 6212 01e1 41e1 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 5000 0300 0000 0000 0000 028c 0600 0000 003b 853e 0f00 ff00 002b 4000 80a0 000b. Basic mode control register 0x1000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:10:18:--:--:--, model 33 rev. 2. No specific information is known about this transceiver type. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. ===================================================== -James Zhu From greearb@candelatech.com Sun Dec 23 23:24:01 2001 From: greearb@candelatech.com (Ben Greear) Date: Sun Dec 23 23:24:01 2001 Subject: [tulip] Changing MAX_UNITS to a configurable value? Message-ID: <3C26ADBA.1020309@candelatech.com> I find myself wanting to run gobs of 4-port NICs in my machines and the tulip driver (in 2.4.17), by default, will handle only 8. There is a #define (MAX_UNITS) that looks like it will raise this number to, say, 32..... To keep from having to change source code, I'd like to either make the max-units a module parameter, or a compile time option in 'make xconfig'. Does anyone have any preference for either of those options? I'm thinking that the receive queue and transmit queue length might be other good options for a similar change... Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From becker@scyld.com Mon Dec 24 01:47:00 2001 From: becker@scyld.com (Donald Becker) Date: Mon Dec 24 01:47:00 2001 Subject: [tulip] Changing MAX_UNITS to a configurable value? In-Reply-To: <3C26ADBA.1020309@candelatech.com> Message-ID: On Sun, 23 Dec 2001, Ben Greear wrote: > I find myself wanting to run gobs of 4-port NICs in my > machines This is a very unusual requirement. It's reasonable to expect someone with such a configuration to modify documented constants at the top of the source file. > and the tulip driver (in 2.4.17), by default, will > handle only 8. There is a #define (MAX_UNITS) that looks > like it will raise this number to, say, 32..... Check carefully: this is a limit only on the number of interfaces that you can pass module options to, not the number of supported interfaces. #define MAX_UNITS 8 /* More are supported, limit only on options */ > To keep from having to change source code, I'd like to either > make the max-units a module parameter, or a compile time > option in 'make xconfig'. The reason for the limit is that each module option needs a initialized array element. > I'm thinking that the receive queue and transmit queue length > might be other good options for a similar change... It's much less import today than a few years ago, but these were constants because it makes the compiled code more efficient. See the comment: /* Keep the descriptor ring sizes a power of two for efficiency. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From greearb@candelatech.com Mon Dec 24 02:05:01 2001 From: greearb@candelatech.com (Ben Greear) Date: Mon Dec 24 02:05:01 2001 Subject: [tulip] Changing MAX_UNITS to a configurable value? References: Message-ID: <3C26D391.4070203@candelatech.com> Donald Becker wrote: > On Sun, 23 Dec 2001, Ben Greear wrote: > > >>I find myself wanting to run gobs of 4-port NICs in my >>machines >> > > This is a very unusual requirement. It's reasonable to expect someone > with such a configuration to modify documented constants at the top of > the source file. Perhaps, but if I can make it configurable through the xconfig process, it will be much easier to explain to potential customers of mine. For some reason, editing source code scares some people :) As long as we default to decent values, and have help information in the config process, I don't see any problems with the extra configurability... Actually, it would probably make more sense to have some more global settings that influenced all (most) drivers. For instance, for buffer sizes: 'small', 'big', 'huge' (and let individual drivers deal with their internals to keep powers-of-two and/or cache alignment tweakings in order...) We could have another setting to influence the number of devices the drivers can support 'few' /* 0-4 */, 'several' /* 0-8 */, 'many' /* 0-24 */, 'bunches'/* 0-64 */ > > >>and the tulip driver (in 2.4.17), by default, will >>handle only 8. There is a #define (MAX_UNITS) that looks >>like it will raise this number to, say, 32..... >> > > Check carefully: this is a limit only on the number of interfaces that > you can pass module options to, not the number of supported interfaces. > > #define MAX_UNITS 8 /* More are supported, limit only on options */ Hrm, maybe I have a PCI/Card problem then. I see 8 ports (two of the 3 4-port NICs), but not the last 4 ports. lspci does not show them either. Does that mean anything to you? > > >>To keep from having to change source code, I'd like to either >>make the max-units a module parameter, or a compile time >>option in 'make xconfig'. >> > > The reason for the limit is that each module option needs a initialized > array element. So, it's just a memory usage issue, correct? Thanks for the feedback, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From becker@scyld.com Mon Dec 24 02:17:00 2001 From: becker@scyld.com (Donald Becker) Date: Mon Dec 24 02:17:00 2001 Subject: [tulip] Changing MAX_UNITS to a configurable value? In-Reply-To: <3C26D391.4070203@candelatech.com> Message-ID: On Mon, 24 Dec 2001, Ben Greear wrote: > Donald Becker wrote: > > On Sun, 23 Dec 2001, Ben Greear wrote: > Actually, it would probably make more sense to have some more global > settings that influenced all (most) drivers. For instance, for buffer > sizes: 'small', 'big', 'huge' (and let individual drivers deal with > their internals to keep powers-of-two and/or cache alignment tweakings > in order...) We could have another setting to influence the number of > devices the drivers can support 'few' /* 0-4 */, 'several' /* 0-8 */, > 'many' /* 0-24 */, 'bunches'/* 0-64 */ I don't see that this makes sense. > > #define MAX_UNITS 8 /* More are supported, limit only on options */ > Hrm, maybe I have a PCI/Card problem then. I see 8 ports (two of the > 3 4-port NICs), but not the last 4 ports. lspci does not show them > either. Does that mean anything to you? The interface handling code in the kernel might have a limit, or the tulip driver you are using might have one. You could try my driver to check the latter. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From goemon@anime.net Mon Dec 24 02:33:00 2001 From: goemon@anime.net (Dan Hollis) Date: Mon Dec 24 02:33:00 2001 Subject: [tulip] Changing MAX_UNITS to a configurable value? In-Reply-To: Message-ID: On Mon, 24 Dec 2001, Donald Becker wrote: > On Sun, 23 Dec 2001, Ben Greear wrote: > > I find myself wanting to run gobs of 4-port NICs in my > > machines > This is a very unusual requirement. It's reasonable to expect someone > with such a configuration to modify documented constants at the top of > the source file. It's becoming more common each day. For example I run 16 ports on one of our core BGP linux routers, and another ISP I know runs 20. Quadports these days are very cheap and plentiful. Not so long ago, it was unusual for anyone to have more than 4 IDE drives in their system. Now 8 drives or more are common, thanks to 3ware and other cards, combined with onboard IDE. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] From greearb@candelatech.com Mon Dec 24 20:00:00 2001 From: greearb@candelatech.com (Ben Greear) Date: Mon Dec 24 20:00:00 2001 Subject: [tulip] Tulip + 3 4-port NICs problems... Message-ID: <3C27CF50.1040500@candelatech.com> I'm still working on getting my 3 4-port DLINK NICs working. I'm using the kernel's tulip driver (can't get pci-scan.o to load, lots of unresolved symbols...) I modified the tulip driver, changing MAX_UNITS to 24, TX-Queue to 64, and RX-Queue to 128. The driver now discovers all of the ports, but shows some IRQ problems with some. Also, when I do an ifconfig eth1 up, a **second** eth1 interface shows up in 'ifconfig -a'. I'm using a PCI riser card, so there could be a hardware problem... I tried loading an un-modified de4x5 driver, but it only discovered the first 8 ports... Any ideas or suggestions will be welcomed! (ifconfig -a, lspci -v, output found below) Here's what I get when loading tulip the driver: Dec 24 16:39:03 lanf1 kernel: Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) Dec 24 16:39:03 lanf1 kernel: tulip0: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip0: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth1: Digital DS21143 Tulip rev 65 at 0xcc00, 00:80:C8:B9:6B:54, IRQ 9. Dec 24 16:39:03 lanf1 kernel: PCI: Enabling device 04:06.0 (0000 -> 0003) Dec 24 16:39:03 lanf1 kernel: PCI: No IRQ known for interrupt pin A of device 04:06.0. Please try using pci=biosirq. Dec 24 16:39:03 lanf1 kernel: PCI: Setting latency timer of device 04:06.0 to 64 Dec 24 16:39:03 lanf1 kernel: tulip1: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip1: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth2: Digital DS21143 Tulip rev 65 at 0xc400, 00:80:C8:B9:6B:53, IRQ 0. Dec 24 16:39:03 lanf1 kernel: PCI: Enabling device 04:05.0 (0000 -> 0003) Dec 24 16:39:03 lanf1 kernel: PCI: No IRQ known for interrupt pin A of device 04:05.0. Please try using pci=biosirq. Dec 24 16:39:03 lanf1 kernel: PCI: Setting latency timer of device 04:05.0 to 64 Dec 24 16:39:03 lanf1 kernel: tulip2: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip2: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip2: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth3: Digital DS21143 Tulip rev 65 at 0xc080, 00:80:C8:B9:6B:52, IRQ 0. Dec 24 16:39:03 lanf1 kernel: PCI: Enabling device 04:04.0 (0000 -> 0003) Dec 24 16:39:03 lanf1 kernel: PCI: No IRQ known for interrupt pin A of device 04:04.0. Please try using pci=biosirq. Dec 24 16:39:03 lanf1 kernel: PCI: Setting latency timer of device 04:04.0 to 64 Dec 24 16:39:03 lanf1 kernel: tulip3: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip3: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip3: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth4: Digital DS21143 Tulip rev 65 at 0xc000, 00:80:C8:B9:6B:51, IRQ 0. Dec 24 16:39:03 lanf1 kernel: tulip4: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip4: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip4: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth5: Digital DS21143 Tulip rev 65 at 0xbc00, 00:80:C8:B9:6C:40, IRQ 11. Dec 24 16:39:03 lanf1 kernel: tulip5: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip5: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip5: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth6: Digital DS21143 Tulip rev 65 at 0xb880, 00:80:C8:B9:6C:3F, IRQ 9. Dec 24 16:39:03 lanf1 kernel: tulip6: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip6: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip6: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth7: Digital DS21143 Tulip rev 65 at 0xb800, 00:80:C8:B9:6C:3E, IRQ 10. Dec 24 16:39:03 lanf1 kernel: tulip7: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip7: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip7: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth8: Digital DS21143 Tulip rev 65 at 0xb480, 00:80:C8:B9:6C:3D, IRQ 11. Dec 24 16:39:03 lanf1 kernel: tulip8: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip8: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip8: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:03 lanf1 kernel: eth9: Digital DS21143 Tulip rev 65 at 0xac00, 00:80:C8:B9:6C:54, IRQ 10. Dec 24 16:39:03 lanf1 kernel: tulip9: EEPROM default media type Autosense. Dec 24 16:39:03 lanf1 kernel: tulip9: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:03 lanf1 kernel: tulip9: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:04 lanf1 kernel: eth10: Digital DS21143 Tulip rev 65 at 0xa880, 00:80:C8:B9:6C:53, IRQ 11. Dec 24 16:39:04 lanf1 kernel: tulip10: EEPROM default media type Autosense. Dec 24 16:39:04 lanf1 kernel: tulip10: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:04 lanf1 kernel: tulip10: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:04 lanf1 kernel: eth11: Digital DS21143 Tulip rev 65 at 0xa800, 00:80:C8:B9:6C:52, IRQ 11. Dec 24 16:39:04 lanf1 kernel: tulip11: EEPROM default media type Autosense. Dec 24 16:39:04 lanf1 kernel: tulip11: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 24 16:39:04 lanf1 kernel: tulip11: MII transceiver #1 config 3100 status 7869 advertising 01e1. Dec 24 16:39:04 lanf1 kernel: eth12: Digital DS21143 Tulip rev 65 at 0xa480, 00:80:C8:B9:6C:51, IRQ 9. Here's what ifconfig -a looks like after eth1-8 has been set UP (notice the repeated eth1-8 entries at the end of the listing) [root@lanf1 root]# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:03:47:C2:A6:D2 inet addr:192.168.1.55 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:740 errors:0 dropped:0 overruns:0 frame:0 TX packets:766 errors:0 dropped:0 overruns:0 carrier:0 collisions:325 RX bytes:95945 (93.6 Kb) TX bytes:589324 (575.5 Kb) eth1 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:54 inet addr:172.1.1.210 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth2 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:53 inet addr:172.1.1.211 Bcast:172.1.1.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 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth3 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:52 inet addr:172.1.1.212 Bcast:172.1.1.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 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth4 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:51 inet addr:172.1.1.213 Bcast:172.1.1.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 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth5 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:40 inet addr:172.1.1.214 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth6 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:3F inet addr:172.1.1.215 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth7 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:3E inet addr:172.1.1.216 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth8 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:3D inet addr:172.1.1.217 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth9 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:54 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth10 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:53 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth11 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:52 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth12 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:51 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:2 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth1 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:54 inet addr:172.1.1.210 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth2 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:53 inet addr:172.1.1.211 Bcast:172.1.1.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 eth3 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:52 inet addr:172.1.1.212 Bcast:172.1.1.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 eth4 Link encap:Ethernet HWaddr 00:80:C8:B9:6B:51 inet addr:172.1.1.213 Bcast:172.1.1.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 eth5 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:40 inet addr:172.1.1.214 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth6 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:3F inet addr:172.1.1.215 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth7 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:3E inet addr:172.1.1.216 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth8 Link encap:Ethernet HWaddr 00:80:C8:B9:6C:3D inet addr:172.1.1.217 Bcast:172.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 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:225 errors:0 dropped:0 overruns:0 frame:0 TX packets:225 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:74276 (72.5 Kb) TX bytes:74276 (72.5 Kb) [root@lanf1 root]# [root@lanf1 root]# lspci 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801BAM PCI (rev 11) 00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (ICH2) (rev 11) 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 11) 00:1f.2 USB Controller: Intel Corporation 82801BA(M) USB (Hub A) (rev 11) 00:1f.3 SMBus: Intel Corporation 82801BA(M) SMBus (rev 11) 00:1f.4 USB Controller: Intel Corporation 82801BA(M) USB (Hub B) (rev 11) 00:1f.5 Multimedia audio controller: Intel Corporation 82801BA(M) AC'97 Audio (rev 11) 01:08.0 Ethernet controller: Intel Corporation 82801BA(M) Ethernet (rev 03) 01:09.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 01:0a.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 01:0c.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 02:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 02:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 04:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 04:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 04:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 04:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) [root@lanf1 root]# lspci -v 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) Subsystem: Intel Corporation: Unknown device 4532 Flags: bus master, fast devsel, latency 0 Capabilities: [88] #09 [f104] 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation: Unknown device 4532 Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11 Memory at f8000000 (32-bit, prefetchable) [size=64M] Memory at ffa80000 (32-bit, non-prefetchable) [size=512K] Capabilities: [dc] Power Management version 2 00:1e.0 PCI bridge: Intel Corporation 82801BAM PCI (rev 11) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=04, sec-latency=32 I/O behind bridge: 0000a000-0000dfff Memory behind bridge: fef00000-ff8fffff Prefetchable memory behind bridge: f6700000-f6afffff 00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (ICH2) (rev 11) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 11) (prog-if 80 [Master]) Subsystem: Intel Corporation: Unknown device 4532 Flags: bus master, medium devsel, latency 0 I/O ports at ffa0 [size=16] 00:1f.2 USB Controller: Intel Corporation 82801BA(M) USB (Hub A) (rev 11) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 4532 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at ef40 [size=32] 00:1f.3 SMBus: Intel Corporation 82801BA(M) SMBus (rev 11) Subsystem: Intel Corporation: Unknown device 4532 Flags: medium devsel, IRQ 9 I/O ports at efa0 [size=16] 00:1f.4 USB Controller: Intel Corporation 82801BA(M) USB (Hub B) (rev 11) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 4532 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at ef80 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation 82801BA(M) AC'97 Audio (rev 11) Subsystem: Intel Corporation: Unknown device 4656 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at e800 [size=256] I/O ports at ef00 [size=64] 01:08.0 Ethernet controller: Intel Corporation 82801BA(M) Ethernet (rev 03) Subsystem: Intel Corporation: Unknown device 3013 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K] I/O ports at df00 [size=64] Capabilities: [dc] Power Management version 2 01:09.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 32 Bus: primary=01, secondary=04, subordinate=04, sec-latency=32 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: ff500000-ff7fffff Prefetchable memory behind bridge: 00000000f6900000-00000000f6900000 Capabilities: [dc] Power Management version 1 01:0a.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 32 Bus: primary=01, secondary=03, subordinate=03, sec-latency=32 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: ff200000-ff4fffff Prefetchable memory behind bridge: 00000000f6800000-00000000f6800000 Capabilities: [dc] Power Management version 1 01:0c.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 32 Bus: primary=01, secondary=02, subordinate=02, sec-latency=32 I/O behind bridge: 0000a000-0000afff Memory behind bridge: fef00000-ff1fffff Prefetchable memory behind bridge: 00000000f6700000-00000000f6700000 Capabilities: [dc] Power Management version 1 02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at a480 [size=128] Memory at ff1ff000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff0c0000 [disabled] [size=256K] 02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at a800 [size=128] Memory at ff1ff400 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff100000 [disabled] [size=256K] 02:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at a880 [size=128] Memory at ff1ff800 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff140000 [disabled] [size=256K] 02:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at ac00 [size=128] Memory at ff1ffc00 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff180000 [disabled] [size=256K] 03:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at b480 [size=128] Memory at ff4ff000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff3c0000 [disabled] [size=256K] 03:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at b800 [size=128] Memory at ff4ff400 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff400000 [disabled] [size=256K] 03:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at b880 [size=128] Memory at ff4ff800 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff440000 [disabled] [size=256K] 03:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at bc00 [size=128] Memory at ff4ffc00 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff480000 [disabled] [size=256K] 04:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 64 I/O ports at c000 [size=128] Memory at ff500000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at [disabled] [size=256K] 04:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 64 I/O ports at c080 [size=128] Memory at ff500400 (32-bit, non-prefetchable) [size=1K] Expansion ROM at [disabled] [size=256K] 04:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 64 I/O ports at c400 [size=128] Memory at ff500800 (32-bit, non-prefetchable) [size=1K] Expansion ROM at [disabled] [size=256K] 04:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: D-Link System Inc: Unknown device 1112 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at cc00 [size=128] Memory at ff7ffc00 (32-bit, non-prefetchable) [size=1K] Expansion ROM at ff780000 [disabled] [size=256K] -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From ingi@ementor.se Wed Dec 26 15:23:00 2001 From: ingi@ementor.se (Ingvaldur Sigurjonsson) Date: Wed Dec 26 15:23:00 2001 Subject: [tulip] Tulip kernel driver module and PCMCIA schemes ! Message-ID: Hi, I just switched from using the tulip_cb from PCMCIA package to using just the tulip driver from the kernel source (2.4.17). When I put my card, which is D-Link DFE-660 10/100", the cardinfo reports it being a "CardBus hotplug device". It doesn't read anything from /etc/pcmcia either, so I have to manual do a 'modprobe -k tulip'. I can successfully set up the card for two different network configuration I have (home/work), but it would be convenient to have it use the 'Scheme' provided in PCMCIA as I had it when using PCMCIA driver, i.e. Slot 0 = Work, Slot 1 = Home. Can anyone please advise on 1) have the kernel driver loaded when the card is inserted 2) How do activate different configurations (aka scheme) when in different slots. I also have a Wireless (D-Link Air, DWL-650) for use at home. Therefor I do not need the tulip driver loaded at all times. Regards Ingvaldur From melih@bellsouth.net Thu Dec 27 00:28:01 2001 From: melih@bellsouth.net (Melih Onvural) Date: Thu Dec 27 00:28:01 2001 Subject: [tulip] setup Message-ID: could someone hook me up with a rundown on how to set tulip up. I've been trying for about a week now and I'm using a Linux Anypoint USB network. I have a driver for it, but nothing seems to want to work. any amount of aid would ge greatly appreciated. thank you! Melih From chitra_gs@hotmail.com Fri Dec 28 18:35:00 2001 From: chitra_gs@hotmail.com (chitra ganesan) Date: Fri Dec 28 18:35:00 2001 Subject: [tulip] help - driver for nic Message-ID: ------=_NextPart_001_0007_01C1908D.B9CB9540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello sir, We are doing engineering from Bharathiar university ,India. We are involved in the design of a driver program for Network Adapter car= d.we happened to see u'r pgms for tulip cards on the net.Sir but we don't= know how to start , =20 where to start , =20 what are the books & knowledge we should have, whether should we know in detail about various pins & functions of nic & = .. We are badly in need of help. Kindly guide us how to start & where to start. we are very sorry for disturbing u. Awaiting u'r reply. email : chitra_gs@hotmail.com thank u, urs faithfully, g.chitra c.d.vijayagowriGet more from the Web. FREE MSN Explorer download : http:= //explorer.msn.com ------=_NextPart_001_0007_01C1908D.B9CB9540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hello sir,=
       We are doing engineering= from Bharathiar university ,India.
We are involved in the design of a= driver program for Network Adapter card.we happened to see u'r pgms for = tulip cards on the net.Sir but we don't know how to start ,
where to = start ,
what are the books & knowledge we should have,
whether= should we know in detail about various pins & functions of nic &= ..
We are badly in need of help.
Kindly guide us how to start &= ; where to start.
we are very sorry for disturbing u.
Awaiting u'r = reply.
email : chitra_gs@hotm= ail.com
thank u,
urs faithfully,
g.chitra
c.d.vij= ayagowri

 

Get= more from the Web. FREE MSN Explorer download : http://explorer.msn.com

------=_NextPart_001_0007_01C1908D.B9CB9540-- From orlandorocha@digi.com.br Sat Dec 29 14:19:01 2001 From: orlandorocha@digi.com.br (Orlando Rocha) Date: Sat Dec 29 14:19:01 2001 Subject: [tulip] Tulip and Presario 1700 Message-ID: <00a301c1909d$9119fff0$93e0d9c8@MESTRADO> This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01C1908C.C9171980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I thank all, the hint was very important! I managed to install the = network adapter in the Presario 1700.It=B4s possible to install in = kernel 2.2.19 and 2.4.X; RH and Slackware.=20 I thank a lot all. Orlando Rocha ------=_NextPart_000_00A0_01C1908C.C9171980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
I thank all, the hint was very = important! I managed=20 to install the network adapter in the Presario 1700.It=B4s possible to = install in=20 kernel 2.2.19 and 2.4.X; RH and Slackware. 
I thank a lot all.
Orlando = Rocha
------=_NextPart_000_00A0_01C1908C.C9171980-- From orlandorocha@digi.com.br Mon Dec 31 13:48:00 2001 From: orlandorocha@digi.com.br (Orlando Rocha) Date: Mon Dec 31 13:48:00 2001 Subject: [tulip] Hi All Message-ID: <00f801c1922b$a9e1a170$93e0d9c8@MESTRADO> This is a multi-part message in MIME format. ------=_NextPart_000_00F5_01C1921A.4ECDF510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Happy new year wishes to all! ------=_NextPart_000_00F5_01C1921A.4ECDF510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Happy new year wishes to all!
------=_NextPart_000_00F5_01C1921A.4ECDF510-- From glory_2_god@studyshare.net Mon Dec 31 16:23:01 2001 From: glory_2_god@studyshare.net (Troy Farrell) Date: Mon Dec 31 16:23:01 2001 Subject: [tulip] Linux 2.4.8, 2.4.17 and KNE111TX with Lite-On PNIC-II rev 37 Message-ID: <3C30D6EF.9030208@studyshare.net> Hi Everyone. I think it beneficial for the workers of tulip/linux kernel driver magic to get the following information. I'm running 2.4.8 unpatched and 2.4.17 unpatched, both on an Athlon 1.0/266. I can use the tulip driver from 2.4.8 with no problems (I'm using modules). When I use the 2.4.17 module, the card will *rarely* autonegotiate with my NetGear Hub. It will also fail to talk to the hub if I force it to any of 10baseT(autonegotiate), 10baseT-FDX, 100baseTx, 100baseTx-FDX, 10baseT(forced). If I let it try to negotiate, roughly 80% of the time it will fail in a stream of error messages (tulip_debug=5): Dec 31 13:05:01 enoch kernel: Linux Tulip driver version 0.9.15-pre9 (Nov 6, 200 1) Dec 31 13:05:01 enoch kernel: PCI: Found IRQ 5 for device 00:0a.0 Dec 31 13:05:01 enoch kernel: 00:0a.0: tulip_mwi_config() Dec 31 13:05:01 enoch kernel: 00:0a.0: MWI config cacheline=16, csr0=00a09000 Dec 31 13:05:01 enoch kernel: eth0: Lite-On PNIC-II rev 37 at 0xe89da000, 00:C0: F0:75:DE:DD, IRQ 5. Dec 31 13:05:18 enoch kernel: eth0: tulip_up(), irq==5. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4008010 new csr5=0xe40080 10. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 e4008010, fff4ee39. Dec 31 13:05:18 enoch kernel: eth0: PNIC2 10baseT link beat good. Dec 31 13:05:18 enoch kernel: eth0: Too much work during an interrupt, csr5=0xe4 008010. (1) (0,0,17) Dec 31 13:05:18 enoch kernel: eth0: exiting interrupt, csr5=0xe4000010. Dec 31 13:05:18 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:18 enoch kernel: eth0: On Entry to Nway, csr6=e0000000. Dec 31 13:05:18 enoch kernel: eth0: Done tulip_up(), CSR0 fef89000, CSR5 e452000 0 CSR6 e1002202. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4670005 new csr5=0xe46600 00. Dec 31 13:05:18 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4670005 new csr5=0xe46600 00. Dec 31 13:05:18 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4670005 new csr5=0xe46600 00. Dec 31 13:05:18 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4670005 new csr5=0xe46600 00. Dec 31 13:05:18 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4668800 new csr5=0xe46600 00. Dec 31 13:05:18 enoch kernel: eth0: Re-enabling interrupts, e4668800. Dec 31 13:05:18 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:18 enoch kernel: eth0: interrupt csr5=0xe4670005 new csr5=0xe46600 00. Dec 31 13:05:18 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:20 enoch kernel: eth0: interrupt csr5=0xec668010 new csr5=0xec6680 00. Dec 31 13:05:20 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec668010, fff7fffd. Dec 31 13:05:20 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:20 enoch kernel: eth0: Setting CSR6 e1840000/e1002202 CSR12 000000 cc. Dec 31 13:05:20 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:20 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:20 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:20 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:20 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:20 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:20 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:21 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:21 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:21 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:21 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:21 enoch kernel: eth0: interrupt csr5=0xe4630004 new csr5=0xe46600 00. Dec 31 13:05:21 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:21 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:21 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:21 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:21 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:21 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:21 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:23 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:23 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:23 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:23 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:23 enoch kernel: eth0: exiting interrupt, csr5=0xe4670004. Dec 31 13:05:23 enoch kernel: eth0: interrupt csr5=0xe4670004 new csr5=0xe46600 00. Dec 31 13:05:23 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:23 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:23 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:23 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:23 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:23 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:23 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:25 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:25 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:25 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:25 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:25 enoch kernel: eth0: interrupt csr5=0xe4630004 new csr5=0xe46600 00. Dec 31 13:05:25 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:25 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:25 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:25 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:25 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:25 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:25 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:26 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:26 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:26 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:26 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:26 enoch kernel: eth0: exiting interrupt, csr5=0xe4670004. Dec 31 13:05:26 enoch kernel: eth0: interrupt csr5=0xe4670004 new csr5=0xe46600 00. Dec 31 13:05:26 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:26 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:26 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:26 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:26 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:26 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:26 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:28 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:28 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:28 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:28 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:28 enoch kernel: eth0: interrupt csr5=0xe4630004 new csr5=0xe46600 00. Dec 31 13:05:28 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:28 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:28 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:28 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:28 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:28 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:28 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:30 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:30 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:30 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:30 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:30 enoch kernel: eth0: exiting interrupt, csr5=0xe4670004. Dec 31 13:05:30 enoch kernel: eth0: interrupt csr5=0xe4670004 new csr5=0xe46600 00. Dec 31 13:05:30 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:30 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:30 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:30 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:30 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:30 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:30 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:31 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:31 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:31 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:31 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:31 enoch kernel: eth0: interrupt csr5=0xe4630004 new csr5=0xe46600 00. Dec 31 13:05:31 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:31 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:31 enoch kernel: eth0: PNIC2 link status interrupt 000000ce, CSR5 ec668000, fff7ff7d. Dec 31 13:05:31 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:31 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:31 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:31 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:33 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:33 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:33 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:33 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:33 enoch kernel: eth0: exiting interrupt, csr5=0xe4670004. Dec 31 13:05:33 enoch kernel: eth0: interrupt csr5=0xe4670004 new csr5=0xe46600 00. Dec 31 13:05:33 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. Dec 31 13:05:33 enoch kernel: eth0: interrupt csr5=0xec668000 new csr5=0xec6680 00. Dec 31 13:05:33 enoch kernel: eth0: PNIC2 link status interrupt 000000ca, CSR5 ec668000, fff7ff7d. Dec 31 13:05:33 enoch kernel: eth0: Ugh! Link blew? Dec 31 13:05:33 enoch kernel: eth0: Restarting PNIC2 autonegotiation, csr14=fff3 fffd. Dec 31 13:05:33 enoch kernel: eth0: On Entry to Nway, csr6=e1842002. Dec 31 13:05:33 enoch kernel: eth0: exiting interrupt, csr5=0xe4000000. Dec 31 13:05:34 enoch kernel: eth0: interrupt csr5=0xec008010 new csr5=0xec0080 00. Dec 31 13:05:34 enoch kernel: eth0: PNIC2 link status interrupt 40a1d0cc, CSR5 ec008010, fff7fffd. Dec 31 13:05:34 enoch kernel: eth0: Switching to 100baseTx based on link negotia tion 01e0 & 40a1 = 00a0. Dec 31 13:05:34 enoch kernel: eth0: Setting CSR6 e1840000/e1000200 CSR12 000000 cc. Dec 31 13:05:34 enoch kernel: eth0: interrupt csr5=0xe4630004 new csr5=0xe46600 00. Dec 31 13:05:34 enoch kernel: eth0: exiting interrupt, csr5=0xe4660000. The 'Ugh! Link blew?' messages result from my pulling the plug to try and kick the card into working - It's worked before :) At the moment, I'm still using 2.4.8, 'cause it works, but I though you'd appreciate the error report. Troy -- And the glory of the LORD shall be revealed, and all flesh shall see it together: for the mouth of the LORD hath spoken it. Isaiah 40.5