From neofire_ind@hotmail.com Wed, 4 Apr 2001 21:58:43 -0400
Date: Wed, 4 Apr 2001 21:58:43 -0400
From: Matt T neofire_ind@hotmail.com
Subject: [tulip-bug] Tulip.o problems on Mandrake 7.1 securenet system...
This is a multi-part message in MIME format.
------=_NextPart_000_00A3_01C0BD52.6A96A780
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi, I am having trouble compiling tulip.o on my Mandrake 7.1 linux box ( =
running on a 400 mhz ( Celeron ) processor with 64 mb RAM and a 10 gb HD =
).
When I run the command "uname -r", I get "2.2.17-21mdksecure".
I have a LinkSys ( well, it was sold under the name NetworkEverywhere ( =
which is a subsidiery of LinkSys ) ) NC100 NIC.
I was wandering if anybody here had the compiled versions of tulip.o and =
pci-scan.o that could be sent to me. A colleauge of mine says that =
there is another module that should come with all of this, but I don't =
think so. He might be confusing that with the header file kern_compat.c =
or the tulip-diag.c files...
I will include the errors that I get when I try to compile tulip.c and =
pci-scan.c ( in the file, there is actually only the errors for one of =
the compilations, because they are both the same ). The command I used =
to compile was:
gcc -DMODULE -D__KERNEL__ -O6 -c tulip.c
and another one too that yielded similar results that looks like:
gcc -DMODULE -D__KERNEL__ -O6 -c tulip.c -I/usr/src/linux/
Thank you for your time,
Sincerely,
Matt T
------=_NextPart_000_00A3_01C0BD52.6A96A780
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi, I am having trouble compiling =
tulip.o on my=20
Mandrake 7.1 linux box ( running on a 400 mhz ( Celeron ) processor with =
64 mb=20
RAM and a 10 gb HD ).
When I run the command "uname -r", I =
get=20
"2.2.17-21mdksecure".
I have a LinkSys ( well, it was sold =
under the name=20
NetworkEverywhere ( which is a subsidiery of LinkSys ) ) NC100 =
NIC.
I was wandering if anybody here had the =
compiled=20
versions of tulip.o and pci-scan.o that could be sent to me. A =
colleauge=20
of mine says that there is another module that should come with all of =
this, but=20
I don't think so. He might be confusing that with the header file=20
kern_compat.c or the tulip-diag.c files...
I will include the errors that I get =
when I try to=20
compile tulip.c and pci-scan.c ( in the file, there is actually only the =
errors=20
for one of the compilations, because they are both the same ). The =
command=20
I used to compile was:
gcc -DMODULE -D__KERNEL__ -O6 -c=20
tulip.c
and another one too that yielded =
similar results=20
that looks like:
gcc -DMODULE -D__KERNEL__ -O6 -c =
tulip.c=20
-I/usr/src/linux/
Thank you for your time,
Sincerely,
Matt T
------=_NextPart_000_00A3_01C0BD52.6A96A780--
From muizelaar@home.com Tue, 17 Apr 2001 18:35:55 -0400
Date: Tue, 17 Apr 2001 18:35:55 -0400
From: Jeff Muizelaar muizelaar@home.com
Subject: [tulip-bug] ASIX AX88140 doesn't work under 2.4 kernel
I am having dificulty getting an ASIX AX88140 ethernet card to work under
the 2.4.3 kernel.
It works perfectly under a 2.2.19 kernel and is found properly, but when
trying the 2.4.3 kernel it fails with the message:
tulip: eth1: MMIO region (0x0@0x0) unavailable, aborting
tulip-diag still detects the card, here is the results of it under 2.4.3:
tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Macronix 98715 PMAC adapter at 0xbc00.
Port selection is 10mpbs-serial 100baseTx scrambler, full-duplex.
Transmit started, Receive started, full-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit unit is set to store-and-forward.
Index #2: Found a ASIX AX88140 adapter at 0xc000.
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 MAC/filter registers are 18cac000 00007f8a 80000000 00000000.
Use '-a' or '-aa' to show device registers,
'-e' to show EEPROM contents, -ee for parsed contents,
or '-m' or '-mm' to show MII management registers.
From wizzy@videor.com Fri, 20 Apr 2001 14:44:46 +0200
Date: Fri, 20 Apr 2001 14:44:46 +0200
From: wizzy@videor.com wizzy@videor.com
Subject: [tulip-bug] Ethernet
Hi, i've a Conexant MiniPCI Ethernet card, and i'v follow
the instruction (pci-scan.*, kern_* ecc ecc) for configure
mi ethernet, but at the bottom, ping not ( send & return )
any package.... (sorry for my english...)
I've tryied to use your tulip.c driver, but at last the card not
send and ot received anything...
Plese, Can you help me ?
I'v a Compaq Presarop 1700 17-XL469
please: help me!!!!!!
--
==---------------------------------------------------------------------==
******** One Ring to Find Them All One Ring to Rule Them *******
******** One Ring to Bring Them All and in Darkness Bind Them *******
==---------------------------------------------------------------------==
From "Lord Of The Rings" J.R.R. Tolkien
From simentt@dolphinics.no Fri, 20 Apr 2001 17:21:53 +0200
Date: Fri, 20 Apr 2001 17:21:53 +0200
From: Simen Timian Thoresen simentt@dolphinics.no
Subject: [tulip-bug] KNE111TX PNIC-II problems....
Now that Kingston has stopped making the previous quite ok KNE110TX
(with the old PNIC chip and the link-regaining problems I've reported earlier)
my supplyer has switched to KNE111TX. These cards use the PNIC-II chip
as reported by the standard linux driver (base 2.2.16 and 2.2.19).
Aparently the supplied tulip driver works ok, but that success is only skin
deep;
When doing data 'streams' (ftp transfers, nfs copy operations, ls -lR on nfs
filesystems etc) the card just stops reciving data. When doing an nfs
operation the client is put in the 'D' state as reported by ps, and can not be
terminated. ^C'ing the ftp transfer and restarting it works ok, but the next
attempt does not fare much better. To the naked eye it seems that only a
low numer of blocks of a certain block size can be transferred - perhaps
some 60Kbytes or thereabouts pr block.
Does this make any sense?
I know the problem is card/driver related, changing to a 3C595 solved the
problem, and as stated the symptoms were the same on both stock 2.2.16
and 2.2.19 kernels.
I can supply additional information if needed, as this system is still in test.
Yours,
-Simen
--
Why are there penguins embedded in my toaster?
Er det rart?
The gnu RART-project on http://valinor.dolphinics.no:1080/~simentt/rart
From neofire_ind@hotmail.com Sun, 22 Apr 2001 09:25:05 -0400
Date: Sun, 22 Apr 2001 09:25:05 -0400
From: Matt T neofire_ind@hotmail.com
Subject: [tulip-bug] I cannot get tulip to load my card up, even though it was compiled fine...
This is a multi-part message in MIME format.
------=_NextPart_000_0011_01C0CB0E.1DDA4B80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I have compiled a new version of tulip ( I tried this same version on =
another computer with the same card but a different OS ( actually, it =
was the same computer ) and it worked, but it won't now ).
On bootup it gives me the message: initializing interface eth0: delaying =
initialization :::failed:::
Can someone help me? I am on a mandrake linux box and the tulip module =
compiled with only one warning ( something about modversion.mod or =
something... ), but it produced tulip.o.
I ran `insmod tulip` and then `depmod -a`...
I then restarted, and that is what it has been giving me since...
If anybody can tell me if this is a platform or tulip problem and/or =
help me, I would greatly appreciate it!
Sincerely,
Matt
------=_NextPart_000_0011_01C0CB0E.1DDA4B80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I have compiled a new version of tulip =
( I tried=20
this same version on another computer with the same card but a different =
OS (=20
actually, it was the same computer ) and it worked, but it won't now=20
).
On bootup it gives me the message: =
initializing=20
interface eth0: delaying initialization :::failed:::
Can someone help me? I am on a =
mandrake linux=20
box and the tulip module compiled with only one warning ( something =
about=20
modversion.mod or something... ), but it produced tulip.o.
I ran `insmod tulip` and then `depmod=20
-a`...
I then restarted, and that is what it =
has been=20
giving me since...
If anybody can tell me if this is a =
platform or=20
tulip problem and/or help me, I would greatly appreciate =
it!
Sincerely,
Matt
------=_NextPart_000_0011_01C0CB0E.1DDA4B80--
From becker@scyld.com Sun, 22 Apr 2001 10:58:44 -0400 (EDT)
Date: Sun, 22 Apr 2001 10:58:44 -0400 (EDT)
From: Donald Becker becker@scyld.com
Subject: [tulip-bug] I cannot get tulip to load my card up, even though
it was compiled fine...
On Sun, 22 Apr 2001, Matt T wrote:
> I have compiled a new version of tulip ( I tried this same version on
> another computer with the same card but a different OS ( actually, it
> was the same computer ) and it worked, but it won't now ).
>
> On bootup it gives me the message: initializing interface eth0:
> delaying initialization :::failed:::
What type of card?
What does 'lspci' or /proc/pci report about the chip type?
What driver version?
What the message when you tried to load the driver? (Use 'dmesg'.)
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 Sun, 22 Apr 2001 16:31:40 -0400 (EDT)
Date: Sun, 22 Apr 2001 16:31:40 -0400 (EDT)
From: Donald Becker becker@scyld.com
Subject: [tulip-bug] I cannot get tulip to load my card up, even though
it was compiled fine...
On Sun, 22 Apr 2001, Matt T wrote:
> > > On bootup it gives me the message: initializing interface eth0:
> > > delaFrom becker@scyld.com Sun, 22 Apr 2001 16:31:40 -0400 (EDT)
Date: Sun, 22 Apr 2001 16:31:40 -0400 (EDT)
From: Donald Becker becker@scyld.com
Subject: [tulip-bug] I cannot get tulip to load my card up, even though
it was compiled fine...
On Sun, 22 Apr 2001, Matt T wrote:
> > > On bootup it gives me the message: initializing interface eth0:
> > > delaying initialization :::failed:::
> >
> > What type of card?
> > What does 'lspci' or /proc/pci report about the chip type?
> > What driver version?
> > What the message when you tried to load the driver? (Use 'dmesg'.)
>
> ?It is linksys card ( N100 v 2 I think is some extra info about
> it... )
That's likely a ADMtek Comet card.
> ?are lspci and /proc/pci programs? I got no output by them... it couldn't
> even find them. I took a look for /proc/pci and I found it. There was
> nothing written in them.
lspci is a program.
/proc/pci is a pseudo-file that has no contents until you view it.
Run them as
/sbin/lspci
cat /proc/pci
> ?Umm... It is the newest one form scyld.net ( I got it about 3 weeks ago ).
> I don't know the exact numbers...
The exact version number is important.
> ?Well, there wasn't anything in the output of dmesg that had anything to do
> with tulip, eth0, network or anything like that... ( I ran `dmesg | grep
> WORD` where word is the word tulip, eth0, net, pci, and such ).
That means you don't have the tulip module configured. Even if the
driver doesn't find a card, it still reports the version number.
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 ch@h111.hadiko.de Mon, 23 Apr 2001 12:21:08 +0200
Date: Mon, 23 Apr 2001 12:21:08 +0200
From: Christoph Heine ch@h111.hadiko.de
Subject: [tulip-bug] Probems with FastLine-II FO (100BaseFX Card)
Hi!
I've two problems with two FastLine-II FO Cards:
a) There is something wrong with 'TX packets' and 'TX errors'
eth2 Link encap:Ethernet HWaddr 00:00:CB:55:06:12
inet addr:172.20.252.4 Bcast:172.20.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:237758 errors:0 dropped:0 overruns:0 frame:0
TX packets:3048 errors:206356 dropped:0 overruns:1carrier:206356
collisions:0 txqueuelen:100
Interrupt:10 Base address:0x9000
While this seems only to be cosmetically, the other problem is more
noticeable:
b)
Packetloss, from 2% up to 4%. (Which does not occur when I use a
eepro100 with a media converter)
Any ideas what it could be? I also tried the de4x5 driver with de-facto
negative result.
Greetings,
Christoph Heine
Here is the output from varouis tools/messages around the card:
dmesg:
Linux Tulip driver version 0.9.14 (February 20, 2001)
PCI: Found IRQ 12 for device 00:0a.0
eth1: Digital DS21143 Tulip rev 65 at 0x9400, 00:00:CB:55:06:67, IRQ
12.
eth1: EEPROM default media type MII 100baseTx.
eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
block.
eth1: Index #1 - Media AUI (#2) described by a 21143 reset method (5)
block.
eth1: MII transceiver #1 config 2100 status 7809 advertising 0001.
eth1: Advertising 01e1 on PHY 1, previously advertising 0001.
eth1: Advertising 01e1 (to advertise is 01e1).
PCI: Found IRQ 10 for device 00:0b.0
PCI: The same IRQ used for device 00:11.0
eth2: Digital DS21143 Tulip rev 65 at 0x9000, 00:00:CB:55:06:12, IRQ
10.
eth2: EEPROM default media type MII 100baseTx.
eth2: Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
block.
eth2: Index #1 - Media AUI (#2) described by a 21143 reset method (5)
block.
eth2: MII transceiver #1 config 2100 status 7809 advertising 0001.
eth2: Advertising 01e1 on PHY 1, previously advertising 0001.
eth2: Advertising 01e1 (to advertise is 01e1).
eth0: 0 multicast blocks dropped.
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 0x9400.
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.
Internal autonegotiation state is 'Autonegotiation disabled'.
Index #2: Found a Digital DS21143 Tulip adapter at 0x9000.
Port selection is MII, half-duplex.
Transmit started, Receive started, half-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 512.
The NWay status register is 000000c6.
Internal autonegotiation state is 'Autonegotiation disabled'.
Use '-a' or '-aa' to show device registers,
'-e' to show EEPROM contents, -ee for parsed contents,
or '-m' or '-mm' to show MII management registers.
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #1 transceiver registers:
2100 780d 7810 0003 0001 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 4000 0104 3808 0010 0000 0002
0001 0000 0000 0000 0000 0000 0000 0000.
Basic mode control register 0x2100: Auto-negotiation disabled, with
Speed fixed at 100 mbps, full-duplex.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD
10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Link partner information information is not exchanged when in fixed
speed mode.
From Bernd.Raschke@netage.de Mon, 23 Apr 2001 11:08:25 +0200
Date: Mon, 23 Apr 2001 11:08:25 +0200
From: Bernd Raschke Bernd.Raschke@netage.de
Subject: [tulip-bug] Adaptec QuadEther and Kernel 2.4 woes
Hi!
(always wanted to do a "IYFPH[1] woes" subject :-)
Over the weekend i have been trying to get the following combination to
work (without success):
Pentium Pro 200,
Adaptec Quad Ethernet card (4 DEC 21140 AFAIR),
Linux 2.4.3,
tulip driver
With 2.2.x the combination worked like a charm, with 2.4 i got all sorts
of lockups, failed initializaions or just no-go's :-( After lots of %&^$@&!
it drilled down to the following symptoms:
With 2.2 or the alternative driver in 2.4 (de4x5), the tulip driver assigns
every one of the four chips its own interrupt (e.g. 20 through 23) The first
chip (eth0) works fine, bit if i ifconfig eth3 it does not receive any
packets, the interrupt count for eth0 is running up at an anormal speed and
eth3 doesn't get any interrupts at all.
I don't have the complete output from tulip-diag here right now (and the
machine in question is offline), but for eth3 it said someting like "No RX
buffers" and "Interrupt sources pending".
I finally tried the alternative DEC driver, which did the job (and also
shared one interrupt between all four of the chips).
I'm sorry some of the data is a bit foggy (as mentioned, the machine is
offline (in the back of my car :-)) I this is a bug and not just plain
stupidity on my side, i'd be glad to offer help (if only for a limited
time, as this card is supposed to go into production soon).
Regards,
Arty
[1] Insert Your Favorite Problem Here
--
Bernd Raschke, Dipl.-Inf.
NetAge Solutions GmbH, Dingolfinger Str. 6, 81673 München
Tel.: +49-(0)89-666 584-0, Fax : +49-(0)89-666 584-11
Feed the Hungry! Save the Whales! Free the Mallocs!
From simentt@dolphinics.no Tue, 24 Apr 2001 07:58:12 +0200
Date: Tue, 24 Apr 2001 07:58:12 +0200
From: Simen Timian Thoresen simentt@dolphinics.no
Subject: [tulip-bug] KNE111TX PNIC-II problems....
From: "Tom Parker"
> Simen Timian Thoresen wrote:
>
> >I know the problem is card/driver related, changing to a 3C595 solved the
> >problem, and as stated the symptoms were the same on both stock 2.2.16
> >and 2.2.19 kernels.
>
> Have you tried Donald Becker's updated tulip driver from
> http://www.scyld.com ?
>
> This driver has support for more cards, but is incompatible with the 2.4
> series kernel.
>
Now I have tried it (the 0.92t from the test directory). It worked nice on the
system I used to test it, a SMP 2.2.17 with raid and ata100 patches, but I
have not yet confirmed it on my initial problem system here, neither have I
confirmed my initial problems on the 2.2.17 box (I'll try to do that today).
If my test here is positive (meaning that the 0.92t driver fixes the problem on
a system where the problem appears) I'll fire off a mail to whoever is the
kernelside tulip maintainer/integrator.
Is there reason to believe that the 0.92t also will fix my KNE110TX unable-to-
renegotiate-link problem? Is there a tulip changelog available?
So far I'm happy here.
Yours,
-Simen
--
Why are there penguins embedded in my toaster?
Er det rart?
The gnu RART-project on http://valinor.dolphinics.no:1080/~simentt/rart
From becker@scyld.com Mon, 23 Apr 2001 09:34:43 -0400 (EDT)
Date: Mon, 23 Apr 2001 09:34:43 -0400 (EDT)
From: Donald Becker becker@scyld.com
Subject: [tulip-bug] Probems with FastLine-II FO (100BaseFX Card)
On Mon, 23 Apr 2001, Christoph Heine wrote:
> I've two problems with two FastLine-II FO Cards:
>
> a) There is something wrong with 'TX packets' and 'TX errors'
> RX packets:237758 errors:0 dropped:0 overruns:0 frame:0
> TX packets:3048 errors:206356 dropped:0 overruns:1carrier:206356
> collisions:0 txqueuelen:100
> While this seems only to be cosmetically, the other problem is more
> noticeable:
Those errors are *not* cosmetic -- they are reporting a serious probem.
It appears the chip is not properly configured to work with the
transceiver.
> b)
> Packetloss, from 2% up to 4%. (Which does not occur when I use a
> eepro100 with a media converter)
The packet loss is likely connected to the problem reported above.
> Linux Tulip driver version 0.9.14 (February 20, 2001)
Does the card work properly with the unmodified driver from Scyld?
> Linux Tulip driver version 0.9.14 (February 20, 2001)
> PCI: Found IRQ 12 for device 00:0a.0
> eth1: Digital DS21143 Tulip rev 65 at 0x9400, 00:00:CB:55:06:67, IRQ
> 12.
> eth1: EEPROM default media type MII 100baseTx.
> eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
> block.
> eth1: Index #1 - Media AUI (#2) described by a 21143 reset method (5)
> block.
This (modified) driver version has an obvious bug.
> mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
> http://www.scyld.com/diag/index.html
> MII PHY #1 transceiver registers:
> 2100 780d 7810 0003 0001 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 4000 0104 3808 0010 0000 0002
> 0001 0000 0000 0000 0000 0000 0000 0000.
> Basic mode control register 0x2100: Auto-negotiation disabled, with
> Speed fixed at 100 mbps, full-duplex.
Hmmm, curious. Did you set the media type to forced-full-duplex?
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