From lmcclef@lmc.ericsson.se Tue, 31 Oct 2000 16:50:55 -0500
Date: Tue, 31 Oct 2000 16:50:55 -0500
From: Claude LeFrancois (LMC) lmcclef@lmc.ericsson.se
Subject: [vortex] Strange problems with 3c59x
--------------57D586C2B75D8DE6D30FC098
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hello,
I am running RedHat 6.2 on a Dual PIII 866 MHz with 256 MB RAM computer
(Intel 840 chipset at 133 MHz front side bus and AIC-7899 SCSI
controllers). I was using the standard RedHat 6.2 kernel
(2.2.14-5.0smp). The network is 100mbps full duplex at work. The
networking client information is distributed over DHCP. The computer is
equipped with an on-board 3C905C Tornado. The computer was working fine
with the stock RedHat kernel.
But, I decided to upgrade the kernel to 2.2.17 anyway. When I rebooted
the system, I realized the NIC was not able to get its networking
information from DHCP. From this step, I tried a lot of fixes with good
and bad results... I finally enabled the debug info with "debug=7" and
found that the driver had some problems to probe the netwotk connection.
The driver in 2.2.14-5.0smp is 0.99H. I compared the traces and realized
that the version "16Aug00" did not recognize the network properly. I
added the "full_duplex=1 options=4" in that order and I got the card to
work at impressive speeds. I also tested 0.99Qk and 19Oct00 with the
same results. When I provide the above options to the driver, the driver
loads properly but when I do not provide any options and use simply
(insmod 3c59x.o), the card is not working. Is there a problem with the
network auto-sensing or am I mis-using the driver ?
Any help would be really appreciated. I cannot send the logs in mailing
lists but if you require them contact me. I can reproduce the problem
easiliy.
Thank you for your support,
Claude.
--
Claude LeFrançois, System and Network Administrator
Ericsson Research Canada (LMC)
8300 Décarie, Ville Mont-Royal, Québec, Canada, H4P 2P5
Tel: (514) 345-7900 x7579, Fax: (514) 345-6149
Email: lmcclef@lmc.ericsson.se
--------------57D586C2B75D8DE6D30FC098
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I am running RedHat 6.2 on a Dual PIII 866 MHz with 256 MB RAM
computer (Intel 840 chipset at 133 MHz front side bus and AIC-7899 SCSI
controllers). I was using the standard RedHat 6.2 kernel (2.2.14-5.0smp).
The network is 100mbps full duplex at work. The networking client information
is distributed over DHCP. The computer is equipped with an on-board 3C905C
Tornado. The computer was working fine with the stock RedHat kernel.
But, I decided to upgrade the kernel to 2.2.17 anyway. When I rebooted
the system, I realized the NIC was not able to get its networking information
from DHCP. From this step, I tried a lot of fixes with good and bad
results... I finally enabled the debug info with "debug=7" and found that
the driver had some problems to probe the netwotk connection. The driver
in 2.2.14-5.0smp is 0.99H. I compared the traces and realized that the
version "16Aug00" did not recognize the network properly. I added the "full_duplex=1
options=4" in that order and I got the card to work at impressive
speeds. I also tested 0.99Qk and 19Oct00 with the same results. When
I provide the above options to the driver, the driver loads properly but
when I do not provide any options and use simply (insmod 3c59x.o), the
card is not working. Is there a problem with the network auto-sensing or
am I mis-using the driver ?
Any help would be really appreciated. I cannot send the logs in
mailing lists but if you require them contact me. I can reproduce
the problem easiliy.
Thank you for your support,
Claude.
--
Claude LeFrançois, System and Network Administrator
Ericsson Research Canada (LMC)
8300 Décarie, Ville Mont-Royal, Québec, Canada, H4P 2P5
Tel: (514) 345-7900 x7579, Fax: (514) 345-6149
Email: lmcclef@lmc.ericsson.se
--------------57D586C2B75D8DE6D30FC098--
From henrik@larsson.net Sun, 05 Nov 2000 02:49:38 +0100
Date: Sun, 05 Nov 2000 02:49:38 +0100
From: Henrik Larsson henrik@larsson.net
Subject: [vortex] 3c905C-TX
Hello,
I am running Debian Linux 2.2 with kernel 2.2.17 and compiled the 3com
3c90x driver manually when direct support for my kernel wasn't available. I
have the 3c905C-TX card in my Linux box.
I have tried to load the module with and without parameters and it loads
successfully...but it isn't assigned any network interface (device ID),
i.e. "eth0". If the card doesn't get such a "name", I assume that I can't
configure it in my Linux system.
I wondering if anyone here have any ideas where the error or solution to
this problem can be found? I don't know if it depends om the module or not.
Shall I perhaps compile the driver into the kernel instead and skip the module?
I have tested my card with 3c90xcfg and have recieved successful result.
When I load it with 'insmod 3c90x' I'll get...
"3Com 3c90x Version 1.0.0.i 1999 "
...when I have earlier played around with other network cards, those
usually also writes out the device ID that the network cards have been
assigned, i.e. eth0. This one doesn't write it out on the screen nor being
assigned one in the system.
The reason why I "changed" driver to 3c90x is that I for a week now have
used the 3c509 driver which are quite buggy when it is used with my card. I
for example get a lot of TX errors and it also disturbs other network
traffic on my LAN. In other words, it didn't work so well to use that
driver. :-)
Thanks in advance.
Henrik Larsson
henrik@larsson.net
From cachemail@procache.com Sun, 5 Nov 2000 10:11:55 +0330 (IRT)
Date: Sun, 5 Nov 2000 10:11:55 +0330 (IRT)
From: cachemail@procache.com cachemail@procache.com
Subject: [vortex] 3c905C-TX
Dear Henrik
Have you tried the following command after loading the module:
#/etc/rc.d/init.c/network start
If it does not work, I think that maybe rebooting your system can
solve your problem.
You can put it in the kernel or use it as a module. There is no
difference.
Best Regards,
V.Fk
On Sun, 5 Nov 2000, Henrik Larsson wrote:
> Hello,
>
> I am running Debian Linux 2.2 with kernel 2.2.17 and compiled the 3com
> 3c90x driver manually when direct support for my kernel wasn't available. I
> have the 3c905C-TX card in my Linux box.
>
> I have tried to load the module with and without parameters and it loads
> successfully...but it isn't assigned any network interface (device ID),
> i.e. "eth0". If the card doesn't get such a "name", I assume that I can't
> configure it in my Linux system.
>
> I wondering if anyone here have any ideas where the error or solution to
> this problem can be found? I don't know if it depends om the module or not.
> Shall I perhaps compile the driver into the kernel instead and skip the module?
>
> I have tested my card with 3c90xcfg and have recieved successful result.
>
> When I load it with 'insmod 3c90x' I'll get...
> "3Com 3c90x Version 1.0.0.i 1999 "
>
> ...when I have earlier played around with other network cards, those
> usually also writes out the device ID that the network cards have been
> assigned, i.e. eth0. This one doesn't write it out on the screen nor being
> assigned one in the system.
>
> The reason why I "changed" driver to 3c90x is that I for a week now have
> used the 3c509 driver which are quite buggy when it is used with my card. I
> for example get a lot of TX errors and it also disturbs other network
> traffic on my LAN. In other words, it didn't work so well to use that
> driver. :-)
>
> Thanks in advance.
>
> Henrik Larsson
> henrik@larsson.net
>
>
> _______________________________________________
> vortex mailing list
> vortex@scyld.com
> http://www.scyld.com/mailman/listinfo/vortex
>
From sacrificial-spam-address@horizon.com 8 Nov 2000 04:39:01 -0000
Date: 8 Nov 2000 04:39:01 -0000
From: sacrificial-spam-address@horizon.com sacrificial-spam-address@horizon.com
Subject: [vortex] 3c905c ROM enable/disable
I recently got frustrated enough with the fact that the network BIOS in
my 3c905c was delaying the boot sequence all the time to make a DOS boot
floppy and run 3com's 3c90xcfg.exe. I snapshotted the EEPROM before
and after to try to spot the changed bits. A half dozen bits changed,
so I fiddled with the settings some more and collected various other
EEPROM settings until a consistent pattern emerged:
It looks like (the surrounding words are the manufacturer's default)
EEPROM contents (64 words, offset 0):
0x000: 0001 0230 xxxx 9200 0044 0048 5245 6d50
0x008: 2940 0800 0001 0230 xxxx 0010 0000 00aa
0x010: 72a2 0000 0000 0180 0000 0000 0421 10b7
^-- change to 3 for ROM BIOS disable
0x018: 1000 000a 0002 6300 ffb7 b7b7 0000 0000
0x020: 00a8 1234 5600 0000 0000 0000 0000 0000
0x028: 0000 0000 0000 0000 0000 0000 0000 0000
0x030: ffff ffff ffff ffff ffff ffff ffff ffff
0x038: ffff ffff ffff ffff ffff ffff ffff ffff
The word-wide EEPROM checksum is .
Parsing the EEPROM of a 3Com Vortex/Boomerang:
3Com Node Address 00:01:02:30:xx:xx (used as a unique ID only).
OEM Station address 00:01:02:30:xx:xx (used as the ethernet address).
Manufacture date (MM/DD/YYYY) 2/4/2000, division H, product ER.
Options: none.
Vortex format checksum is incorrect (xxxx vs. 10b7).
Cyclone format checksum is incorrect (0xa6 vs. 0xa8).
Hurricane format checksum is incorrect (0x8f vs. 0xa8).
When I turn the boot ROM off, the diag program messes with various
settings (like always setting the adapter to 10baseT, sigh), but
the only bit that is consistently associated with the boot ROM
settings is 0200 in word 0x14.
There appears to be no checksum. At least, nothing else changes in
a corresponding way.
I haven't hacked vortex-diag.c to let me fiddle that bit yet, but
from observing the EEPROM after adjusting the settings, that looks
like it.
I just thought this might be useful to someone.
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Wed, 8 Nov 2000 15:21:45 +0100 (CET)
Date: Wed, 8 Nov 2000 15:21:45 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3c905c ROM enable/disable
On 8 Nov 2000 sacrificial-spam-address@horizon.com wrote:
> I recently got frustrated enough with the fact that the network BIOS in
> my 3c905c was delaying the boot sequence all the time to make a DOS boot
> floppy and run 3com's 3c90xcfg.exe.
I've never seen this (making of a boot floppy from EEPROM) and I have a
lot of 905C cards. However, the main question is: do you want to boot off
the card's EEPROM ? The computers that I bought during the last 6 months
have an option in BIOS that allow to boot from network or not, just like
booting off the floppy, HD or CDROM. I just disable network booting (or
put it lower than floppy/HD) and never bother about EEPROM content.
However, if you need to boot off EEPROM, you'd better rewrite the EEPROM
content; I think that vortex-diag is capable of doing this and the image
can be created with Etherboot.
> There appears to be no checksum. At least, nothing else changes in
> a corresponding way.
For 905C cards, the checksumming is either strange or non-existent!
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From sacrificial-spam-address@horizon.com 8 Nov 2000 15:11:05 -0000
Date: 8 Nov 2000 15:11:05 -0000
From: sacrificial-spam-address@horizon.com sacrificial-spam-address@horizon.com
Subject: [vortex] 3c905c ROM enable/disable
>From Bogdan.Costescu@IWR.Uni-Heidelberg.De Wed Nov 08 14:21:55 2000
Delivered-To: colin@horizon.com
Delivered-To: sacrificial-spam-address@horizon.com
Date: Wed, 8 Nov 2000 15:21:45 +0100 (CET)
From: Bogdan Costescu
To: sacrificial-spam-address@horizon.com
cc: vortex@scyld.com
Subject: Re: [vortex] 3c905c ROM enable/disable
In-Reply-To: <20001108043901.7109.qmail@science.horizon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 8 Nov 2000 sacrificial-spam-address@horizon.com wrote:
>> I recently got frustrated enough with the fact that the network BIOS in
>> my 3c905c was delaying the boot sequence all the time to make a DOS boot
>> floppy and run 3com's 3c90xcfg.exe.
Bogdan Costescu replied:
> I've never seen this (making of a boot floppy from EEPROM) and I have a
> lot of 905C cards. However, the main question is: do you want to boot off
> the card's EEPROM ? The computers that I bought during the last 6 months
> have an option in BIOS that allow to boot from network or not, just like
> booting off the floppy, HD or CDROM. I just disable network booting (or
> put it lower than floppy/HD) and never bother about EEPROM content.
> However, if you need to boot off EEPROM, you'd better rewrite the EEPROM
> content; I think that vortex-diag is capable of doing this and the image
> can be created with Etherboot.
Um, perhaps I was unclear. There are *two* EEPROMs on the card.
One is a 64K "boot ROM". It starts with the "55aa" BIOS signature
and contains x86 code.
The other, which vortex-diag refers to as "the" EEPROM, is a small
serial EEPROM with 128 bytes of config data, like the MAC address,
transciever mode (10/100 half/full duplex), and so on.
The boot ROM I don't want or need; I just ended up getting it by
looking for a good cheap network card and finding a 3c905 available.
3com supply a DOS utility to adjust (some of) "the" EEPROM settings.
One of the settings disables the boot ROM, so the BIOS doesn't see it.
This speeds up booting, because it doesn't display a message and wait
for a timeout. I hadn't used it because I don't boot DOS, and Mr. "Wonderful"
Becker's vortex-diag.c doesn't let you fiddle that particular setting
I was recompiling kernels a lot and got annoyed at the delay. So I put
DOS on a floppy and added the 3com utility. Then I backed up the boot
ROM (just to be safe) from Linux, and adjusted the setting. The boot
ROM went away. (As opposed to, say, changing the boot signature.)
I thought the analysis might be worth sharing.
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Wed, 8 Nov 2000 21:46:38 +0100 (CET)
Date: Wed, 8 Nov 2000 21:46:38 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3c905c ROM enable/disable
On 8 Nov 2000 sacrificial-spam-address@horizon.com wrote:
> 3com supply a DOS utility to adjust (some of) "the" EEPROM settings.
> One of the settings disables the boot ROM, so the BIOS doesn't see it.
As I wrote in my previous message, if BIOS doesn't even look for the boot
ROM, it doesn't matter if it's enabled or not and what its content is, so
you don't need to disable it.
Now the question is: are there BIOS-es that can boot off network (so they
try to execute boot ROM code) and do not provide a way to disable this ?
Only if this is true, disabling boot ROM is the only way to avoid BIOS to
try to boot off it.
> This speeds up booting, because it doesn't display a message and wait
> for a timeout.
Absolutely true. That's why I turn off network booting in BIOS.
> I thought the analysis might be worth sharing.
It is! Just that the whole analysis probably took you a lot of time, while
changing the boot sequence is a 30 seconds job 8-)
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From rudy@edsons.demon.nl Thu, 09 Nov 2000 01:09:29 +0100
Date: Thu, 09 Nov 2000 01:09:29 +0100
From: Rudy Zijlstra rudy@edsons.demon.nl
Subject: [vortex] 3c905c ROM enable/disable
Hmmm,
I've not been playing with network booting lately, but I remember that the
code contained in the boot rom on an ethernet card would get executed whether
the mainboard supported network boot or not. Actually, I do not think that
the mainboard network boot makes use of the NIC boot rom. They are just two
different solutions for the same problem.
Thoses NIC boot roms existed long before mainboards started supporting
network boot.
Just my 2c.
Rudy
Bogdan Costescu wrote:
> On 8 Nov 2000 sacrificial-spam-address@horizon.com wrote:
>
> > 3com supply a DOS utility to adjust (some of) "the" EEPROM settings.
> > One of the settings disables the boot ROM, so the BIOS doesn't see it.
>
> As I wrote in my previous message, if BIOS doesn't even look for the boot
> ROM, it doesn't matter if it's enabled or not and what its content is, so
> you don't need to disable it.
> Now the question is: are there BIOS-es that can boot off network (so they
> try to execute boot ROM code) and do not provide a way to disable this ?
> Only if this is true, disabling boot ROM is the only way to avoid BIOS to
> try to boot off it.
>
> > This speeds up booting, because it doesn't display a message and wait
> > for a timeout.
>
> Absolutely true. That's why I turn off network booting in BIOS.
>
> > I thought the analysis might be worth sharing.
>
> It is! Just that the whole analysis probably took you a lot of time, while
> changing the boot sequence is a 30 seconds job 8-)
>
> Sincerely,
>
> Bogdan Costescu
>
> IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
> Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
> Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
> E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
>
> _______________________________________________
> vortex mailing list
> vortex@scyld.com
> http://www.scyld.com/mailman/listinfo/vortex
From braganca@cenpes.petrobras.com.br Tue, 14 Nov 2000 15:06:54 -0200
Date: Tue, 14 Nov 2000 15:06:54 -0200
From: braganca@cenpes.petrobras.com.br braganca@cenpes.petrobras.com.br
Subject: [vortex] =?us-ascii?B?M2M1OXguYyBjb21waWxlIGVycm9ycwA=?=
Hello all,
Purpose: Wol on a 3C905C
Problem: Machine awake after a power loss but not after a shutdown
Suspect: Current driver (3c59x.c V0.99H) do not leave NIC in sleep mode
properly
Trying to compile the driver 3c59x.c:v0.99Qk 7/5/2000 from Donald Becker
I
followed the script in http://www.scyld.com/network/updates.html
When compiling 3c59x.c and pci-scan.c I got:
Erros found compiling 3c59x.c:
___________________________________________________________________________
[root@s2 modules]# gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c 3c59x.c
In file included from 3c59x.c:112:
kern_compat.h:164: parse error before `0'
kern_compat.h:168: warning: type defaults to `int' in declaration of
`mark_bh'
kern_compat.h:168: warning: parameter names (without types) in function
declaration
kern_compat.h:168: conflicting types for `mark_bh'
/usr/include/asm/softirq.h:101: previous declaration of `mark_bh'
kern_compat.h:168: warning: data definition has no type or storage class
kern_compat.h:168: parse error before `}'
gcc: Internal compiler error: program cc1 got fatal signal 11
[root@s2 modules]#
Erros found compiling pci-scan.c:
____________________________________________________________________________
[root@s2 modules]# gcc -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -Wall
-Wstrict-prototypes -O6 -c pci-scan.c
In file included from pci-scan.c:67:
kern_compat.h:164: parse error before `0'
kern_compat.h:168: warning: type defaults to `int' in declaration of
`mark_bh'
kern_compat.h:168: warning: parameter names (without types) in function
declaration
kern_compat.h:168: warning: data definition has no type or storage class
kern_compat.h:168: parse error before `}'
[root@s2 modules]#
Please Help!!
Aditional information:
Linux Kernel 2.2.14
egcs-1.1.2
glibc-2.1.2
Thanks all
Ricardo
From becker@scyld.com Tue, 14 Nov 2000 14:03:41 -0500 (EST)
Date: Tue, 14 Nov 2000 14:03:41 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] =?us-ascii?B?M2M1OXguYyBjb21waWxlIGVycm9ycwA=?=
On Tue, 14 Nov 2000 braganca@cenpes.petrobras.com.br wrote:
> Erros found compiling 3c59x.c:
> ___________________________________________________________________________
> [root@s2 modules]# gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c 3c59x.c
> In file included from 3c59x.c:112:
> kern_compat.h:164: parse error before `0'
> kern_compat.h:168: warning: type defaults to `int' in declaration of
> `mark_bh'
You've got a buggy compiler.
> Aditional information:
> Linux Kernel 2.2.14
> egcs-1.1.2
> glibc-2.1.2
Adding a joining the continued lines, or adding a few spaces in
kern_compat.h will work around this pre-processor bug.
Add the spaces around the *_bit(0,..) functions to make them read
*_bit( 0,..)
#define netif_pause_tx_queue(dev) \
(test_and_set_bit( 0, (void*)&(dev)->tbusy))
#define netif_unpause_tx_queue(dev) \
do { clear_bit( 0, (void*)&(dev)->tbusy); } while (0)
#define netif_resume_tx_queue(dev) \
do { clear_bit( 0, (void*)&(dev)->tbusy); mark_bh(NET_BH); } while (0)
#endif
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 braganca@cenpes.petrobras.com.br Fri, 17 Nov 2000 07:59:47 -0200
Date: Fri, 17 Nov 2000 07:59:47 -0200
From: braganca@cenpes.petrobras.com.br braganca@cenpes.petrobras.com.br
Subject: [vortex] 3c59x.c compile errors
The driver compiles OK after joining continued lines
WOL finaly works and NIC goes to Full Duplex without the need of options
line
THANKS!!!
----- Repassado por Ricardo Silva Nunes Braganca/CENPES/Petrobras em
17/11/00 07:52 -----
Donald Becker
cc: vortex@scyld.com
Enviado Por: Assunto: Re: [vortex] 3c59x.c compile
vortex-admin@ errors
scyld.com
14/11/00
17:03
On Tue, 14 Nov 2000 braganca@cenpes.petrobras.com.br wrote:
> Erros found compiling 3c59x.c:
>
___________________________________________________________________________
> [root@s2 modules]# gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c
3c59x.c
> In file included from 3c59x.c:112:
> kern_compat.h:164: parse error before `0'
> kern_compat.h:168: warning: type defaults to `int' in declaration of
> `mark_bh'
You've got a buggy compiler.
> Aditional information:
> Linux Kernel 2.2.14
> egcs-1.1.2
> glibc-2.1.2
Adding a joining the continued lines, or adding a few spaces in
kern_compat.h will work around this pre-processor bug.
Add the spaces around the *_bit(0,..) functions to make them read
*_bit( 0,..)
#define netif_pause_tx_queue(dev) \
(test_and_set_bit( 0, (void*)&(dev)->tbusy))
#define netif_unpause_tx_queue(dev) \
do { clear_bit( 0, (void*)&(dev)->tbusy); } while (0)
#define netif_resume_tx_queue(dev) \
do { clear_bit( 0, (void*)&(dev)->tbusy); mark_bh(NET_BH); } while (0)
#endif
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 paul.wilson@accnet.net.au Sun, 19 Nov 2000 13:21:08 +1100
Date: Sun, 19 Nov 2000 13:21:08 +1100
From: Paul Wilson paul.wilson@accnet.net.au
Subject: [vortex] Fw: IRQ 0 on PCI card
Re-post on correct mailing list..
Are there other BIOS settings I should be looking at?
I will get the BIOS version and vender when I go on-site.
Paul
----- Original Message -----
From: "Paul Wilson"
To: <3c509@scyld.com>
Sent: Saturday, 18 November 2000 3:44 PM
Subject: IRQ 0 on PCI card
Hi,
I have tried and read but I can't get this PCI 3Com card to work !!
I have read the http://www.scyld.com/expert/irq-conflict.html
and confirmed that the BIOS PnP OS is Disabled
Any other things I could try :>>
===
Diag data:
[root@accnet01 3c59x]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:10:5A:6D:31:A3
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Base address:0x5800
====messages===
3c59x.c:v0.99Qk 7/5/2000 Donald Becker, becker@scyld.com
http://www.scyld.com/network/vortex.html
The PCI BIOS has not enabled the device at 0/144! Updating PCI command
0001->0005.
eth1: Overriding PCI latency timer (CFLT) setting of 0, new value is 32.
eth1: 3Com 3c905B Cyclone 100baseTx at 0x5800, 00:10:5a:6d:31:a3, IRQ 0
*** Warning: IRQ 0 is unlikely to work! ***
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 786d.
MII transceiver found at address 0, status 786d.
Enabling bus-master transmits and whole-frame receives.
[root@accnet01 /root]# cat /proc/interrupts
CPU0
0: 1877933 XT-PIC timer
1: 159 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 955486 XT-PIC serial
5: 356849 XT-PIC serial
10: 29007 XT-PIC WD8013
11: 15 XT-PIC aha152x
13: 1 XT-PIC fpu
14: 34688 XT-PIC ide0
15: 6 XT-PIC ide1
[root@accnet01 3c59x]# ./vortex-diag
vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0x5800.
This chip has not been assigned a valid IRQ, and will not function.
This must be fixed in the PCI BIOS setup. The device driver has no way
of changing the PCI IRQ settings.
See http://www.scyld.com/expert/irq-conflict.html for more information.
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.
==
[root@accnet01 3c59x]# cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel 82439HX Triton II (rev 2).
Medium devsel. Master Capable. Latency=32.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371SB PIIX3 ISA (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable. No
bursts.
Bus 0, device 7, function 1:
IDE interface: Intel 82371SB PIIX3 IDE (rev 0).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32.
I/O at 0xffa0 [0xffa1].
Bus 0, device 17, function 0:
VGA compatible controller: S3 Inc. ViRGE (rev 6).
Medium devsel. Master Capable. Latency=64. Min Gnt=4.Max Lat=255.
Non-prefetchable 32 bit memory at 0xf8000000 [0xf8000000].
Bus 0, device 18, function 0:
Ethernet controller: 3Com 3C905B 100bTX (rev 48).
Medium devsel. Master Capable. Latency=32. Min Gnt=10.Max Lat=10.
I/O at 0x5800 [0x5801].
From paul.wilson@accnet.net.au Sun, 19 Nov 2000 13:31:12 +1100
Date: Sun, 19 Nov 2000 13:31:12 +1100
From: Paul Wilson paul.wilson@accnet.net.au
Subject: [vortex] Re: [3c509] IRQ 0 on PCI card
Thanks I have reposted to vortex and I will try get BIOS make and version PC
is at a mates place
Do you know of other BIOS settings that influence this behaviour.
eg Do I switch all IRQ to PCI some are reserved for ISA!
Is there anyway to search these mailling lists?
Once again thanks.
Paul
----- Original Message -----
From: "Donald Becker"
To: "Paul Wilson"
Cc: <3c509@scyld.com>
Sent: Saturday, 18 November 2000 4:17 PM
Subject: Re: [3c509] IRQ 0 on PCI card
On Sat, 18 Nov 2000, Paul Wilson wrote:
> I have tried and read but I can't get this PCI 3Com card to work !!
>
> I have read the http://www.scyld.com/expert/irq-conflict.html
> and confirmed that the BIOS PnP OS is Disabled
What type of BIOS?
> 3c59x.c:v0.99Qk 7/5/2000 Donald Becker, becker@scyld.com
> http://www.scyld.com/network/vortex.html
> The PCI BIOS has not enabled the device at 0/144! Updating PCI command
> 0001->0005.
Bad...
> eth1: Overriding PCI latency timer (CFLT) setting of 0, new value is 32.
Bad...
> eth1: 3Com 3c905B Cyclone 100baseTx at 0x5800, 00:10:5a:6d:31:a3, IRQ 0
> *** Warning: IRQ 0 is unlikely to work! ***
Very Bad.
> 3c509 mailing list
> 3c509@scyld.com
The "vortex" mailing list is the correct one for 3c905 (vs. the ISA 509)
problems.
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
From becker@scyld.com Sat, 18 Nov 2000 22:12:07 -0500 (EST)
Date: Sat, 18 Nov 2000 22:12:07 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] Re: [3c509] IRQ 0 on PCI card
On Sun, 19 Nov 2000, Paul Wilson wrote:
> > eth1: 3Com 3c905B Cyclone 100baseTx at 0x5800, 00:10:5a:6d:31:a3, IRQ 0
> > *** Warning: IRQ 0 is unlikely to work! ***
...
> Thanks I have reposted to vortex and I will try get BIOS make and version PC
> is at a mates place
> Do you know of other BIOS settings that influence this behaviour.
> eg Do I switch all IRQ to PCI some are reserved for ISA!
You must have at least one free IRQ for the PCI bus. You can't assign all
to the ISA bus.
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 wilsonp@accnet.net.au Sun, 19 Nov 2000 14:38:18 +1100
Date: Sun, 19 Nov 2000 14:38:18 +1100
From: Paul Wilson wilsonp@accnet.net.au
Subject: [vortex] Re: [3c509] IRQ 0 on PCI card
I'm wondering if I use another PCI NIC (tulip.o) will I get same problem
ie is it the BIOS PCI PnP settings forcing this IRQ zero.
Paul
----- Original Message -----
From: "Donald Becker"
To: "Paul Wilson"
Cc:
Sent: Sunday, 19 November 2000 2:12 PM
Subject: Re: [3c509] IRQ 0 on PCI card
On Sun, 19 Nov 2000, Paul Wilson wrote:
> > eth1: 3Com 3c905B Cyclone 100baseTx at 0x5800, 00:10:5a:6d:31:a3, IRQ 0
> > *** Warning: IRQ 0 is unlikely to work! ***
...
> Thanks I have reposted to vortex and I will try get BIOS make and version
PC
> is at a mates place
> Do you know of other BIOS settings that influence this behaviour.
> eg Do I switch all IRQ to PCI some are reserved for ISA!
You must have at least one free IRQ for the PCI bus. You can't assign all
to the ISA bus.
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
From becker@scyld.com Sat, 18 Nov 2000 23:08:36 -0500 (EST)
Date: Sat, 18 Nov 2000 23:08:36 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] Re: [3c509] IRQ 0 on PCI card
On Sun, 19 Nov 2000, Paul Wilson wrote:
> I'm wondering if I use another PCI NIC (tulip.o) will I get same problem
> ie is it the BIOS PCI PnP settings forcing this IRQ zero.
Yes, all PCI cards that require an IRQ will have the same 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 paul.wilson@accnet.net.au Sun, 19 Nov 2000 15:16:52 +1100
Date: Sun, 19 Nov 2000 15:16:52 +1100
From: Paul Wilson paul.wilson@accnet.net.au
Subject: [vortex] Re: [3c509] IRQ 0 on PCI card
What other BIOS settings can I try?
ie other than disabling PnP OS .
----- Original Message -----
From: "Donald Becker"
To: "Paul Wilson"
Cc:
Sent: Sunday, 19 November 2000 3:08 PM
Subject: Re: [3c509] IRQ 0 on PCI card
On Sun, 19 Nov 2000, Paul Wilson wrote:
> I'm wondering if I use another PCI NIC (tulip.o) will I get same problem
> ie is it the BIOS PCI PnP settings forcing this IRQ zero.
Yes, all PCI cards that require an IRQ will have the same 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 wilsonp@accnet.net.au Sun, 19 Nov 2000 20:25:55 +1100
Date: Sun, 19 Nov 2000 20:25:55 +1100
From: Paul Wilson wilsonp@accnet.net.au
Subject: [vortex] Re: [3c509] IRQ 0 on PCI card sucess
I updated BIOS IRQ settings in PnP config screen to set them ALL the be
PCI/PnP
half where ISA/Legacy.
You might like to add this to the IRQ page as well..
Thanks
you your reply..
rebooted.. success IRQ given.
==/var/log/messages==
kernel: wd.c: Presently autoprobing (not recommended) for a single card.
kernel: wd.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
kernel: eth0: WD80x3 at 0x300, 00 00 C0 3D E4 52 WD8013, IRQ 10, shared
memory at 0xcc000-0xcffff.
kernel: CSLIP: code copyright 1989 Regents of the University of California
kernel: PPP: version 2.3.3 (demand dialling)
kernel: PPP line discipline registered.
kernel: registered device ppp0
kernel: PPP BSD Compression module registered
kernel: PPP Deflate Compression module registered
kernel: cat uses obsolete /proc/pci interface
kernel: 3c59x.c:v0.99Qk 7/5/2000 Donald Becker, becker@scyld.com
kernel: http://www.scyld.com/network/vortex.html
kernel: eth1: 3Com 3c905B Cyclone 100baseTx at 0xec80, 00:10:5a:6d:31:a3,
IRQ 9
kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate
interface.
kernel: MII transceiver found at address 24, status 7849.
kernel: MII transceiver found at address 0, status 7849.
kernel: Enabling bus-master transmits and whole-frame receives.
=====
cat /proc/pci
IRQ 9 was selected by driver.
Bus 0, device 0, function 0:
Host bridge: Intel 82439HX Triton II (rev 2).
Medium devsel. Master Capable. Latency=32.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371SB PIIX3 ISA (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable. No
bursts.
Bus 0, device 7, function 1:
IDE interface: Intel 82371SB PIIX3 IDE (rev 0).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32.
I/O at 0xffa0 [0xffa1].
Bus 0, device 17, function 0:
VGA compatible controller: S3 Inc. ViRGE (rev 6).
Medium devsel. IRQ 11. Master Capable. Latency=64. Min Gnt=4.Max
Lat=255.
Non-prefetchable 32 bit memory at 0xf8000000 [0xf8000000].
Bus 0, device 18, function 0:
Ethernet controller: 3Com 3C905B 100bTX (rev 48).
Medium devsel. IRQ 9. Master Capable. Latency=64. Min Gnt=10.Max
Lat=10.
I/O at 0xec80 [0xec81].
Non-prefetchable 32 bit memory at 0xfebeff80 [0xfebeff80].
Paul
----- Original Message -----
From: "Donald Becker"
To: "Paul Wilson"
Cc:
Sent: Sunday, 19 November 2000 3:08 PM
Subject: Re: [3c509] IRQ 0 on PCI card
On Sun, 19 Nov 2000, Paul Wilson wrote:
> I'm wondering if I use another PCI NIC (tulip.o) will I get same problem
> ie is it the BIOS PCI PnP settings forcing this IRQ zero.
Yes, all PCI cards that require an IRQ will have the same 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 beyonder@vrx.net Tue, 21 Nov 2000 11:05:32 -0500
Date: Tue, 21 Nov 2000 11:05:32 -0500
From: Beyonder beyonder@vrx.net
Subject: [vortex] 3com vortex questions
Where can I find information on whether there is
support for linux slackware driver for my new Dell
which has a 3com 10/100 mini PCI adapter
using EL556nd5.sys driver for windows
it seems to be the vortex card, some form of it anyhow.
I'm using linux 2.2.16 (Slackware 7.1)
I can't seem to get the stuff off the vortex support pages to work.
the RPM did absolutely nothing (literally!) I typed the RPM install
commands, but it didn't change a single file, or extract anything.
just returned to the command line. ??
Thanks!
From dan@vrx.net Tue, 21 Nov 2000 11:58:02 -0500 (EST)
Date: Tue, 21 Nov 2000 11:58:02 -0500 (EST)
From: Dan dan@vrx.net
Subject: [vortex] 3com vortex questions
After some fiddling I got the RPM to work. mostly.
the last step (rpm -i --force netdriver-2.0-*.i386.rpm)
fails dependencies, says it needs /bin/sh which is there.
any ideas?
I tried building updated drivers into the kernel as well, but that fails
as well, the problem looks like the layout of the instructions. it's hard
to tell where the line breaks are supposed to be in the documentation on
the website, if there are supposed to be any (?)
I either get a multiple targets error or some other error during a make
modules compile.
B.
From beyonder@vrx.net Tue, 21 Nov 2000 15:49:43 -0500
Date: Tue, 21 Nov 2000 15:49:43 -0500
From: Beyonder beyonder@vrx.net
Subject: [vortex] 3com vortex questions
I finally figured out what was going on with my install.
I think the docs need a little fleshing out.
Now I'm off to find a video driver for this damn thing.
B.
From berkan@runtime-collective.com Thu, 23 Nov 2000 15:44:42 +0000
Date: Thu, 23 Nov 2000 15:44:42 +0000
From: Berkan Eskikaya berkan@runtime-collective.com
Subject: [vortex] 3c905CX-TXM
Hi,
I recently bought several OEM 3Com NICs. The stickers on the bubble-wrap
said they're 3C980TX, on the cards themselves the model id is given as
3c905CX-TXM.
I haven't been able to get them working so far. The driver loads fine,
I can bring up the eth device, but the network remains unreachable.
The MII transceivers have status 0x0020 which makes me think that things
don't progress beyond the negotiation step.
I have other 3Com cards on the network -- 3c905C-TX [Fast Etherlink]
(rev 74) as reported by lspci -- which work fine, so it's probably not
a network/cabling problem.
I'm including some diagnostics below (vortex-diag/mii-diag output among
others); they will surely make more sense to some of you than this humble
user. At the end of the mail, you can also find debug messages produced
by 3Com's 3c90x driver (which fails at the ifconfig stage).
I'd really appreciate any comments/suggestions.
Cheers,
Berkan
#----------------------------------------------------------------------------
$ lspci -vv
01:05.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink](rev 78)
Subsystem: 3Com Corporation: Unknown device 1000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- .
Unable to perform Auto-negotiation, negotiation complete.
This transceiver has no vendor identification.
I'm advertising 01e0: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
Using an unknown (non 802.3) encapsulation.
Link partner capability is 40a1: 100baseTx 10baseT.
Negotiation completed.
#----------------------------------------------------------------------------
$ vortex-diag -t 17 -p 0xc000 -a -f
vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Assuming a 3c905C Tornado 100baseTx adapter at 0xc000.
Initial window 4, registers values by window:
Window 0: 0000 0000 e4cf 0000 8d8d 00bf ffff 0000.
Window 1: 6300 043e 0700 0000 0000 007f 0000 2000.
Window 2: 0100 2303 b7f5 0000 0000 0000 0052 4000.
Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000.
Window 4: 0000 0000 0000 08c6 0001 8800 0000 8000.
Window 5: 1ffc 0000 0000 1ffc 0800 06de 06c6 a000.
Window 6: 0000 0000 0000 0000 0000 0000 0000 c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0xc000
0xC010: 00000000 00000000 0000000a 00000000
0xC020: 00000020 0f094250 00080000 00001404
0xC030: 00000000 3e5fc1a1 00000000 00080004
Indication enable is 06c6, interrupt enable is 06de.
No interrupt sources are pending.
Transceiver/media interfaces available: 100baseTx 10baseT.
Transceiver type in use: Autonegotiate.
MAC settings: half-duplex.
Station address set to 00:01:03:23:f5:b7.
Configuration options 0052.
#----------------------------------------------------------------------------
$ cat /proc/interrupts
CPU0
0: 7079562 XT-PIC timer
1: 2 XT-PIC keyboard
2: 0 XT-PIC cascade
8: 1 XT-PIC rtc
10: 6 XT-PIC eth1
11: 186566 XT-PIC eth0
13: 1 XT-PIC fpu
14: 6636 XT-PIC ide0
15: 2 XT-PIC ide1
NMI: 0
#----------------------------------------------------------------------------
$ cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(set)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
c000-c07f : eth1
c400-c47f : eth0
f000-f007 : ide0
f008-f00f : ide1
#==========================================================================
$ rmmod 3c59x pci-scan
$ insmod 3c90x.o debug=0x7f
$ dmesg
[...]
init_module: IN
tc90xbc_ScanDevices: IN
Tornado NIC found
3Com device eth1
Bus Mastering enabled by BIOS
Irq = a , IoAddress = c000
FillDeviceStructure: IN
FillDeviceStructure: OUT
ReadCommandLineChanges: IN index=0
SendCount = 40
ReceiveCount=40
FlowControl is enabled by default
DownPollRate is 8 by default
ReadCommandLineChanges: OUT
tc90x_AllocateSharedMemory: In
memoryBaseVirtual = cd7e0000, memoryBasePhysical =d7e0000
tc90x_AllocateSharedMemory: Out
tc90xbc_ScanDevices: OUT
NoAdapter = 1
init_module: OUT
3Com 3c90x Version 1.0.0i 1999
#----------------------------------------------------------------------------
$ ifconfig eth1 11.0.0.1 netmask 255.255.255.0 up
SIOCSIFFLAGS: No such device
SIOCSIFFLAGS: No such device
$ dmesg
[...]
New NICOpen: IN
RegisterAdapter: IN
SA_SHIRQ registering IRQ a
RegisterAdapter: OUT
GetAdapterProperties: IN
intStatus =e000
ioBase =c000
s/w information 1 - Full duplex disabled
s/w info1 - optimize Normal
Adapter supports power management
Adapter has BroadcastRxErrDone
Adapter has MWIErrDone
WOL is connected
GetAdapterProperties: OUT
BasicInitializeAdapter: In
BasicInitializeAdapter: Out with success
TestAdapter: IN
In WaitTimer-Time=7018a3
CHECK_DOWNLOAD_STATUS
Out WaitTimer
In WaitTimer-Time=7018ad
CHECK_DOWNLOAD_STATUS
Out WaitTimer
Packet not picked up by the hardware
TestAdapter: Out with error
NICOpen: TestAdapter failed
NICOpen: Out with error
FreeAdapterResources: IN
Releasing interrupt
Releasing WaitTimer
Releasing memory
Releasing IO port region
FreeAdapterResources: OUT
New NICOpen: IN
RegisterAdapter: IN
SA_SHIRQ registering IRQ a
RegisterAdapter: OUT
GetAdapterProperties: IN
intStatus =e400
ioBase =c000
s/w information 1 - Full duplex disabled
s/w info1 - optimize Normal
Adapter supports power management
Adapter has BroadcastRxErrDone
Adapter has MWIErrDone
WOL is connected
GetAdapterProperties: OUT
BasicInitializeAdapter: In
BasicInitializeAdapter: Out with success
TestAdapter: IN
In WaitTimer-Time=701907
CHECK_DOWNLOAD_STATUS
Out WaitTimer
In WaitTimer-Time=701911
CHECK_DOWNLOAD_STATUS
Out WaitTimer
Packet not picked up by the hardware
TestAdapter: Out with error
NICOpen: TestAdapter failed
NICOpen: Out with error
FreeAdapterResources: IN
Releasing interrupt
Releasing WaitTimer
FreeAdapterResources: OUT
From becker@scyld.com Thu, 23 Nov 2000 11:55:51 -0500 (EST)
Date: Thu, 23 Nov 2000 11:55:51 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] 3c905CX-TXM
On Thu, 23 Nov 2000, Berkan Eskikaya wrote:
> I recently bought several OEM 3Com NICs. The stickers on the bubble-wrap
> said they're 3C980TX, on the cards themselves the model id is given as
> 3c905CX-TXM.
Hmmm, "CX"???
> I haven't been able to get them working so far. The driver loads fine,
> I can bring up the eth device, but the network remains unreachable.
> The MII transceivers have status 0x0020 which makes me think that things
> don't progress beyond the negotiation step.
That status indicates that the transceiver isn't capable of any media type!
Somehow the transceiver is misconfigured.
> user. At the end of the mail, you can also find debug messages produced
> by 3Com's 3c90x driver (which fails at the ifconfig stage).
Please confirm: Even 3Com's driver fails?
> 3c59x.c:v0.99Ra 8/7/2000 Donald Becker, becker@scyld.com
> http://www.scyld.com/network/vortex.html
> PCI ID 920010b7 subsystem ID is 100010b7.
> Found 3c905C Tornado at PCI address 0xc001, mapped IRQ 10.
> eth1: 3Com 3c905C Tornado at 0xc000, 00:01:03:23:f5:b7, IRQ 10
> Internal config register is 1800000, transceivers 0xa.
> 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
> MII transceiver found at address 1, status 24.
> MII transceiver found at address 2, status 24.
> Enabling bus-master transmits and whole-frame receives.
Except for the transceiver status, this looks fine.
> Basic registers of MII PHY #1: 0000 0020 0000 0000 01e0 40a1 0003 0800.
> Basic mode control register 0x0000: Auto-negotiation disabled, with
> Speed fixed at 10 mbps, half-duplex.
Does the card work with 10baseT?
Does running
mii-diag -A 0x01e1
or
mii-diag -A 100baseTx
or
mii-diag -F 100baseTx
change anything?
> Basic mode status register 0x0020 ... 0020.
> Link status: not established.
> Your link partner advertised 40a1: 100baseTx 10baseT.
Curious... autonegotiation took place! You have a dual speed repeater.
> eth1: Initial media type Autonegotiate half-duplex.
> eth1: MII #1 status 0024, link partner capability 40a1, setting half-duplex.
> eth1: vortex_open() irq 10 media status 8000.
> eth1: Media selection timer tick happened, Autonegotiate.
> eth1: MII transceiver has status 0020.
> eth1: Media selection timer finished, Autonegotiate.
This is exactly what I expect the driver to do.
> eth1: Queuing Tx packet, index 0.
> eth1: interrupt, status 8201, latency 10 ticks.
> eth1: Queuing Tx packet, index 1.
> eth1: interrupt, status 8201, latency 3 ticks.
> eth1: Queuing Tx packet, index 2.
> eth1: interrupt, status 8201, latency 8 ticks.
> eth1: Queuing Tx packet, index 3.
> eth1: interrupt, status 8201, latency 3 ticks.
> eth1: Queuing Tx packet, index 4.
> eth1: interrupt, status 8201, latency 2 ticks.
The card appears to be working, at least from the driver's viewpoint.
> $ vortex-diag -t 17 -p 0xc000 -a -f
Did you have to do this? Did the vortex-diag program fail to find the card
on its own?
> vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
> http://www.scyld.com/diag/index.html
> Assuming a 3c905C Tornado 100baseTx adapter at 0xc000.
> Initial window 4, registers values by window:
> Window 0: 0000 0000 e4cf 0000 8d8d 00bf ffff 0000.
> Window 1: 6300 043e 0700 0000 0000 007f 0000 2000.
> Window 2: 0100 2303 b7f5 0000 0000 0000 0052 4000.
> Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000.
> Window 4: 0000 0000 0000 08c6 0001 8800 0000 8000.
> Window 5: 1ffc 0000 0000 1ffc 0800 06de 06c6 a000.
> Window 6: 0000 0000 0000 0000 0000 0000 0000 c000.
> Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
> Vortex chip registers at 0xc000
> 0xC010: 00000000 00000000 0000000a 00000000
> 0xC020: 00000020 0f094250 00080000 00001404
> 0xC030: 00000000 3e5fc1a1 00000000 00080004
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 berkan@runtime-collective.com Thu, 23 Nov 2000 18:41:36 +0000
Date: Thu, 23 Nov 2000 18:41:36 +0000
From: Berkan Eskikaya berkan@runtime-collective.com
Subject: [vortex] 3c905CX-TXM
Hi,
Thanks for the quick reply.
> > on the cards themselves the model id is given as 3c905CX-TXM.
>
> Hmmm, "CX"???
Yes. I couldn't find any reference to 3c905CX at 3Com's site. A Google
search brings back a page at Dell's support site, but they seem to use
3c905C and 3c905CX-TXM interchangeably:
http://support.dell.com/docs/network/128fw/en/intro.htm
> Please confirm: Even 3Com's driver fails?
Yes, I can confirm that. Unless I'm overlooking something extremely obvious
(downloaded their driver -> compiled it as they've specified in their README
-> insmod -> ifconfig as in my previous message), it simply fails at the
ifconfig stage with "SIOCSIFFLAGS: No such device" and the debug messages:
Out WaitTimer
Packet not picked up by the hardware
TestAdapter: Out with error
NICOpen: TestAdapter failed
NICOpen: Out with error
> Does the card work with 10baseT?
> Does running
> mii-diag -A 0x01e1
> or
> mii-diag -A 100baseTx
> or
> mii-diag -F 100baseTx
> change anything?
No. They only caused some register values to change (don't know if this
is significant), but still no link established.
> > $ vortex-diag -t 17 -p 0xc000 -a -f
>
> Did you have to do this? Did the vortex-diag program fail to find the card
> on its own?
Actually I don't remember why I did it like this. Without -t -p, it already
gives:
Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xc000.
Can I send anything else?
Cheers,
Berkan
PS: Of course, I guess there is always the possibility that all 4 cards that
I bought are faulty in some way. Is there anybody else on the list who's
got a 3c905CX-TXM?
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Thu, 23 Nov 2000 20:31:38 +0100 (CET)
Date: Thu, 23 Nov 2000 20:31:38 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3c905CX-TXM
On Thu, 23 Nov 2000, Berkan Eskikaya wrote:
> > mii-diag -A 0x01e1
> > or
> > mii-diag -A 100baseTx
> > or
> > mii-diag -F 100baseTx
> > change anything?
>
> No. They only caused some register values to change (don't know if this
> is significant), but still no link established.
What if the driver gets the MII registers address wrong ?
My Tornado cards produce the init sequence containing:
MII transceiver found at address 24, status 782d.
>From what I've seen in the previous message, the init sequence finds 2
transceivers, at address 1 and 2, which I find a little strange.
So, can you try running 'mii-diag -p 24 eth1' ? The output of your
'mii-diag eth1' looks exactly like mine when I specify an invalid address
for the MII transceiver...
Another (bad) ideea: can you try to run the DOS diagnostic program from
3Com ?
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From berkan@runtime-collective.com Thu, 23 Nov 2000 20:18:32 +0000
Date: Thu, 23 Nov 2000 20:18:32 +0000
From: Berkan Eskikaya berkan@runtime-collective.com
Subject: [vortex] 3c905CX-TXM
On Thu, Nov 23, 2000 at 20:31, Bogdan Costescu wrote:
>
> What if the driver gets the MII registers address wrong ?
> My Tornado cards produce the init sequence containing:
>
> MII transceiver found at address 24, status 782d.
>
> >From what I've seen in the previous message, the init sequence finds 2
> transceivers, at address 1 and 2, which I find a little strange.
> So, can you try running 'mii-diag -p 24 eth1' ?
We'll there is a definite change; mii-diag now reports link beat, but
I still cannot ping anywhere.
Here's the sequence:
$ insmod pci-scan.o debug=7
$ insmod 3c59x-t.o debug=7
$ ifconfig eth1 11.0.0.1 netmask 255.255.255.0 up
$ mii-diag eth1
Basic registers of MII PHY #1: 0000 0020 0000 0000 01e0 40a1 0003 0800.
Basic mode control register 0x0000: Auto-negotiation disabled, with
Speed fixed at 10 mbps, half-duplex.
Basic mode status register 0x0020 ... 0020.
Link status: not established.
Your link partner advertised 40a1: 100baseTx 10baseT.
$ ping 11.0.0.2
PING 11.0.0.2 (11.0.0.2): 56 data bytes
--- 11.0.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
$ mii-diag -p 24 eth1
Using the specified MII PHY index 24.
Basic registers of MII PHY #24: 3000 7829 0041 6800 05e1 40a1 0007 2801.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x7829 ... 782d.
Link status: previously broken, but now reestablished.
Your link partner advertised 40a1: 100baseTx 10baseT.
$ ping 11.0.0.2
PING 11.0.0.2 (11.0.0.2): 56 data bytes
--- 11.0.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
$ mii-diag eth1
Basic registers of MII PHY #1: 0000 0024 0000 0000 01e0 40a1 0003 0800.
Basic mode control register 0x0000: Auto-negotiation disabled, with
Speed fixed at 10 mbps, half-duplex.
You have link beat, and everything is working OK.
Your link partner advertised 40a1: 100baseTx 10baseT.
$ mii-diag -p 24 eth1
Using the specified MII PHY index 24.
Basic registers of MII PHY #24: 3000 782d 0041 6800 05e1 40a1 0007 2801.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner advertised 40a1: 100baseTx 10baseT.
>
> Another (bad) ideea: can you try to run the DOS diagnostic program from
> 3Com ?
>
> Sincerely,
>
> Bogdan Costescu
>
> IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
> Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
> Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
> E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
>
From morton@nortelnetworks.com Thu, 23 Nov 2000 23:16:15 +0000
Date: Thu, 23 Nov 2000 23:16:15 +0000
From: Andrew Morton morton@nortelnetworks.com
Subject: [vortex] 3c905CX-TXM
Donald Becker wrote:
>
> On Thu, 23 Nov 2000, Berkan Eskikaya wrote:
>
> > I recently bought several OEM 3Com NICs. The stickers on the bubble-wrap
> > said they're 3C980TX, on the cards themselves the model id is given as
> > 3c905CX-TXM.
>
> Hmmm, "CX"???
>
Donald,
Richard Gooch has recently picked up two of these -CX cards and they're
not working. He's getting a timout when sending an RxReset command
to the NIC during initialisation.
In the 2.4 driver we loop for 4,000 PCI cycles waiting for the command
to
complete. It's timing out.
I note that 3com's 3c90x.c busywaits for up to one second waiting for
the
command to complete. So as an experiment I've asked Richard to increase
the loop count to 4,000,000.
It seems that 3com have changed something. Interesting that the
new NICs don't work with 3com's driver.
Steven, are you able to shed any light on this? Has something changed
in the 3c905CX-TXM?
From rgooch@ras.ucalgary.ca Thu, 23 Nov 2000 20:55:40 -0700
Date: Thu, 23 Nov 2000 20:55:40 -0700
From: Richard Gooch rgooch@ras.ucalgary.ca
Subject: [vortex] 3c905CX-TXM
Andrew Morton writes:
> Donald Becker wrote:
> >
> > On Thu, 23 Nov 2000, Berkan Eskikaya wrote:
> >
> > > I recently bought several OEM 3Com NICs. The stickers on the bubble-wrap
> > > said they're 3C980TX, on the cards themselves the model id is given as
> > > 3c905CX-TXM.
> >
> > Hmmm, "CX"???
>
> Donald,
>
> Richard Gooch has recently picked up two of these -CX cards and they're
> not working. He's getting a timout when sending an RxReset command
> to the NIC during initialisation.
>
> In the 2.4 driver we loop for 4,000 PCI cycles waiting for the command
> to
> complete. It's timing out.
>
> I note that 3com's 3c90x.c busywaits for up to one second waiting
> for the command to complete. So as an experiment I've asked Richard
> to increase the loop count to 4,000,000.
Which fixes the problem. Everything seems fine now. Throughput is over
11 MB/s, as expected.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
From morton@nortelnetworks.com Fri, 24 Nov 2000 04:48:53 +0000
Date: Fri, 24 Nov 2000 04:48:53 +0000
From: Andrew Morton morton@nortelnetworks.com
Subject: [vortex] 3c905CX-TXM
Richard Gooch wrote:
>
> > I note that 3com's 3c90x.c busywaits for up to one second waiting
> > for the command to complete. So as an experiment I've asked Richard
> > to increase the loop count to 4,000,000.
>
> Which fixes the problem. Everything seems fine now. Throughput is over
> 11 MB/s, as expected.
Ug. How diabolical.
Thanks, Richard. If it's OK I'll whip up a debug patch which we can
use to find out which commands are taking how long and when.
From rgooch@ras.ucalgary.ca Thu, 23 Nov 2000 21:53:44 -0700
Date: Thu, 23 Nov 2000 21:53:44 -0700
From: Richard Gooch rgooch@ras.ucalgary.ca
Subject: [vortex] 3c905CX-TXM
Andrew Morton writes:
> Richard Gooch wrote:
> >
> > > I note that 3com's 3c90x.c busywaits for up to one second waiting
> > > for the command to complete. So as an experiment I've asked Richard
> > > to increase the loop count to 4,000,000.
> >
> > Which fixes the problem. Everything seems fine now. Throughput is over
> > 11 MB/s, as expected.
>
> Ug. How diabolical.
>
> Thanks, Richard. If it's OK I'll whip up a debug patch which we can
> use to find out which commands are taking how long and when.
OK. Oh, and I forgot in my last message: thanks for coming up with a
fix.
BTW: is there any way to make these waits non-busy? This is just
another thing that will screw over scheduling latency. If not, people
who care about latency will be avoiding 3Com cards...
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
From andrewm@uow.edu.au Fri, 24 Nov 2000 21:58:25 +1100
Date: Fri, 24 Nov 2000 21:58:25 +1100
From: Andrew Morton andrewm@uow.edu.au
Subject: [vortex] 3c905CX-TXM
Richard Gooch wrote:
>
> OK. Oh, and I forgot in my last message: thanks for coming up with a
> fix.
s/fix/successful experiment/
I don't know what's going on. There's some deja vu here. We've been
slowly incrementing that timeout as more problems like this crop up.
It underwent a large increase when we discovered that the command which
stalls the download engine can take a long time to complete when there
is a massive collision rate. Again, this is inexplicable because the
command could and should complete immediately because of the way in
which the various threshold registers are programmed.
I'd be very surprised if 3com have suddenly changed the ASICs after
five years, so perhaps there's some interaction with the external
transceiver or somesuch which causes the reset to take a long time.
hmm.. dhinds has changed 3c575_cb.c so that it prints out the ASIC
rev numbers. Cut, paste...
> BTW: is there any way to make these waits non-busy? This is just
> another thing that will screw over scheduling latency. If not, people
> who care about latency will be avoiding 3Com cards...
That's normally OK. It normally terminates within 0-2 PCI cycles.
It's just these wierd cases where it can take a long time. As I recall,
timeouts >2,000 PCI cycles occurred every ten minutes or so under
absolutely wicked testing conditions.
So if you can apply the below 2.4 patch and send the debug output
after a bit of usage (insmod/rmmod/up/down/etc) that would be
helpful. It may be necessary to special-case the RxReset with
some schedule_timeout()s. But what worries me is:
1: We also do RxReset from within the error handler. Possibly at
interrupt time. What to do there?
2: Does it affect other commands?
3: We don't know what's going on.
Incidentally, we still don't know what's going on with Berkan's NIC.
I can certainly understand it going wierd if the initialisation
isn't waiting long enough for the RxReset to complete. But it should
have worked with 3c90x.c because that driver uses a 1-second
timeout.
Berkan, could I suggest that you go back to the original driver (0.99Ra)
and increase all the loop counts? Just do a search for 'CmdInProgress'
and replace all the magical constants (2000, 200, 600) to 2000000 and see
if it starts working.
Richard, silly patch which shows us where the big delays are happening:
--- linux-2.4.0-test11-ac2/drivers/net/3c59x.c Tue Nov 21 20:11:20 2000
+++ linux-akpm/drivers/net/3c59x.c Fri Nov 24 21:53:42 2000
@@ -203,7 +203,7 @@
#include
static char version[] __devinitdata =
-"3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html " "$Revision: 1.102.2.46 $\n";
+"3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html " "$Revision: 1.102.2.40 $\n";
MODULE_AUTHOR("Donald Becker ");
MODULE_DESCRIPTION("3Com 3c59x/3c90x/3c575 series Vortex/Boomerang/Cyclone driver");
@@ -863,7 +863,7 @@
struct vortex_private *vp;
int option;
unsigned int eeprom[0x40], checksum = 0; /* EEPROM contents */
- int i;
+ int i, step;
struct net_device *dev;
static int printed_version;
int retval;
@@ -1025,6 +1025,13 @@
dev->irq);
#endif
+ EL3WINDOW(4);
+ step = (inb(ioaddr + Wn4_NetDiag) & 0x1e) >> 1;
+ printk(KERN_INFO " product code '%c%c' rev %02x.%d date %02d-"
+ "%02d-%02d\n", eeprom[6]&0xff, eeprom[6]>>8, eeprom[0x14],
+ step, (eeprom[4]>>5) & 15, eeprom[4] & 31, eeprom[4]>>9);
+
+
if (pdev && vci->drv_flags & HAS_CB_FNS) {
unsigned long fn_st_addr; /* Cardbus function status space */
unsigned short n;
@@ -1148,14 +1155,19 @@
return retval;
}
-static void wait_for_completion(struct net_device *dev, int cmd)
+#define wait_for_completion(dev, cmd) _wait_for_completion(dev, cmd, __LINE__)
+
+static void _wait_for_completion(struct net_device *dev, int cmd, int line)
{
- int i = 4000;
+ int i;
outw(cmd, dev->base_addr + EL3_CMD);
- while (--i > 0) {
- if (!(inw(dev->base_addr + EL3_STATUS) & CmdInProgress))
+ for (i = 0; i < 4000000; i++) {
+ if (!(inw(dev->base_addr + EL3_STATUS) & CmdInProgress)) {
+ if (i > 1000)
+ printk("wait_for_completion: line=%d, count=%d\n", line, i);
return;
+ }
}
printk(KERN_ERR "%s: command 0x%04x did not complete! Status=0x%x\n",
dev->name, cmd, inw(dev->base_addr + EL3_STATUS));
From berkan@runtime-collective.com Fri, 24 Nov 2000 11:37:59 +0000
Date: Fri, 24 Nov 2000 11:37:59 +0000
From: Berkan Eskikaya berkan@runtime-collective.com
Subject: [vortex] 3c905CX-TXM
On Fri, Nov 24, 2000 at 21:58, Andrew Morton wrote:
> Incidentally, we still don't know what's going on with Berkan's NIC.
> I can certainly understand it going wierd if the initialisation
> isn't waiting long enough for the RxReset to complete. But it should
> have worked with 3c90x.c because that driver uses a 1-second
> timeout.
>
> Berkan, could I suggest that you go back to the original driver (0.99Ra)
> and increase all the loop counts? Just do a search for 'CmdInProgress'
> and replace all the magical constants (2000, 200, 600) to 2000000 and see
> if it starts working.
OK, I've changed all the magical constants to 2000000. Still no link beat
until I did a 'mii-diag -p 24 eth1' as Bogdan suggested yesterday. And like
yesterday, it reports link beat afterwards, but I still cannot ping
anywhere.
Berkan
$ insmod pci-scan.o debug=7
$ insmod 3c59x.o debug=7
$ ifconfig eth1 11.0.0.1 netmask 255.255.255.0 up
$ dmesg
[...]
3c59x.c:v0.99Ra 8/7/2000 Donald Becker, becker@scyld.com
http://www.scyld.com/network/vortex.html
PCI ID 920010b7 subsystem ID is 100010b7.
Found 3c905C Tornado at PCI address 0xc001, mapped IRQ 10.
eth1: 3Com 3c905C Tornado at 0xc000, 00:01:03:23:f5:b7, IRQ 10
Internal config register is 1800000, transceivers 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 1, status 24.
MII transceiver found at address 2, status 24.
Enabling bus-master transmits and whole-frame receives.
PCI ID 12111113 subsystem ID is 92111113.
eth1: Initial media type Autonegotiate half-duplex.
eth1: MII #1 status 0024, link partner capability 40a1, setting half-duplex.
eth1: vortex_open() irq 10 media status 8000.
$ ping 11.0.0.2
PING 11.0.0.2 (11.0.0.2): 56 data bytes
--- 11.0.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
$ mii-diag eth1
Basic registers of MII PHY #1: 0000 0020 0000 0000 01e0 40a1 0003 0800.
Basic mode control register 0x0000: Auto-negotiation disabled, with
Speed fixed at 10 mbps, half-duplex.
Basic mode status register 0x0020 ... 0020.
Link status: not established.
Your link partner advertised 40a1: 100baseTx 10baseT.
$ mii-diag -p 24 eth1
Using the specified MII PHY index 24.
Basic registers of MII PHY #24: 3000 7829 0041 6800 05e1 40a1 0007 2801.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x7829 ... 782d.
Link status: previously broken, but now reestablished.
Your link partner advertised 40a1: 100baseTx 10baseT.
$ mii-diag -p 24 eth1
Using the specified MII PHY index 24.
Basic registers of MII PHY #24: 3000 782d 0041 6800 05e1 40a1 0007 2801.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner advertised 40a1: 100baseTx 10baseT.
$ ping 11.0.0.2
PING 11.0.0.2 (11.0.0.2): 56 data bytes
--- 11.0.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
From berkan@runtime-collective.com Fri, 24 Nov 2000 11:55:45 +0000
Date: Fri, 24 Nov 2000 11:55:45 +0000
From: Berkan Eskikaya berkan@runtime-collective.com
Subject: [vortex] 3c905CX-TXM
On Fri, Nov 24, 2000 at 11:37, Berkan Eskikaya wrote:
>
> OK, I've changed all the magical constants to 2000000. Still no link beat
> until I did a 'mii-diag -p 24 eth1' as Bogdan suggested yesterday. And like
> yesterday, it reports link beat afterwards, but I still cannot ping
> anywhere.
Oops, sorry, loaded the wrong driver. It actually works after changing the
constansts as suggested.
mii-diag still says link not established until I run it with -p 24 but, I
repeat, the network has become reachable after the change of constants
above.
Any other changes/tests you want me to do?
B.
From andrewm@uow.edu.au Fri, 24 Nov 2000 22:55:58 +1100
Date: Fri, 24 Nov 2000 22:55:58 +1100
From: Andrew Morton andrewm@uow.edu.au
Subject: [vortex] 3c905CX-TXM
Berkan Eskikaya wrote:
>
> On Fri, Nov 24, 2000 at 11:37, Berkan Eskikaya wrote:
> >
> > OK, I've changed all the magical constants to 2000000. Still no link beat
> > until I did a 'mii-diag -p 24 eth1' as Bogdan suggested yesterday. And like
> > yesterday, it reports link beat afterwards, but I still cannot ping
> > anywhere.
>
> Oops, sorry, loaded the wrong driver. It actually works after changing the
> constansts as suggested.
>
> mii-diag still says link not established until I run it with -p 24 but, I
> repeat, the network has become reachable after the change of constants
> above.
>
> Any other changes/tests you want me to do?
Cool. Thanks. That's half the problem.
We'll await Richard's results on the timeout issue.
As far as the interface selection problem goes: I'm hoping that
Donald or Bogdan can suggest something for you to try - they
are the experts on that stuff. (Hint).
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Fri, 24 Nov 2000 15:01:03 +0100 (CET)
Date: Fri, 24 Nov 2000 15:01:03 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3c905CX-TXM
On Thu, 23 Nov 2000, Berkan Eskikaya wrote:
> > What if the driver gets the MII registers address wrong ?
> > So, can you try running 'mii-diag -p 24 eth1' ?
> We'll there is a definite change; mii-diag now reports link beat, but
> I still cannot ping anywhere.
>
> $ mii-diag -p 24 eth1
> Using the specified MII PHY index 24.
> Basic registers of MII PHY #24: 3000 7829 0041 6800 05e1 40a1 0007 2801.
Well, I somehow expected that. Page 147 of the documentation says:
"These auto-negotiation registers are accessed through the MII management
interface using a PHY address (PHYAD) of 11000b" = 24.
So on Tornado cards, the internal MII interface (which is always present
according to the docs) is always located at PHYAD = 24. I hope that this
is also true for CardBus devices.
In vortex_probe1(), if MII or NWAY is used, there is a search for the MII
interfaces (there can be more than 1). Why this search suddenly doesn't
work anymore, I don't know; Don, do you have any ideea ? Maybe the
preamble confuses the interface ? Maybe some more checks are needed before
saying "we have a valid MII interface at this PHYAD" ?
A workaround can be a test for IS_TORNADO and always add one interface
with PHYAD = 24, but this still leaves the other 2 (or 4 according to
vortex-diag output) MII interfaces detected. Now I don't understand
something: if there are several MII interfaces and they provide similar
capabilities, how is one of them selected as being the one in use ?
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Fri, 24 Nov 2000 15:29:54 +0100 (CET)
Date: Fri, 24 Nov 2000 15:29:54 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3c905CX-TXM
On Fri, 24 Nov 2000, Andrew Morton wrote:
> hmm.. dhinds has changed 3c575_cb.c so that it prints out the ASIC
> rev numbers. Cut, paste...
I wanted to suggest this too, but from what I've seen in the patch this is
just the info that also vortex-diag is printing. Tornado has at address
0x8 in the PCI configuration space a byte called RevisionId (page 65 and
70); this is supposed to show the ASIC revision. As the documentation is
quite scarce, I have no ideea about relations between the RevisionId, the
EEPROM data and the data written on the chip. Can both Berkan and Richard
take a look at the chip and tell us what the ID is ? (which should look
like 40-0574-xxx or 40-05772-xxx)
For Richard: what are the MII interfaces detected at module init ? is
mii-diag working for you without specifying '-p 24' ?
> > BTW: is there any way to make these waits non-busy?
> That's normally OK. It normally terminates within 0-2 PCI cycles.
> It's just these wierd cases where it can take a long time. As I recall,
> timeouts >2,000 PCI cycles occurred every ten minutes or so under
> absolutely wicked testing conditions.
>
> ...But what worries me is:
> 1: We also do RxReset from within the error handler. Possibly at
> interrupt time. What to do there?
> 2: Does it affect other commands?
> 3: We don't know what's going on.
I haven't checked with a debugger, but I suppose that the compiler is
generating the right code, as it works in most cases (it could optimize,
as the code inside the loop is only reading, not writting anything). If
the code is correct, the only possibility (AFAICS) is that the 'in'
operations finish much more quickly in some cases, which suggests some
kind of caching of PCI reads. But as this only seldomly happens, there
might be some PCI chipset's rules about when to start caching, like too
many reads from the same address in a certain time... Actually, I don't
find this too strange as last year Josip Loncaric posted a message on the
beowulf list with details about memory access throttling by the BX
chipset.
If this is really the case, increasing the loop count will not generate
latency, as the reads will be much faster than normal; however, there is
no count that is guaranteed to work in all the cases 8-(
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From becker@scyld.com Fri, 24 Nov 2000 14:21:41 -0500 (EST)
Date: Fri, 24 Nov 2000 14:21:41 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] 3c905CX-TXM
>> OK. Oh, and I forgot in my last message: thanks for coming up with a
>> fix.
>
> s/fix/successful experiment/
Yes, everyone please keep this in mind.
Register polling should never go on longer than about 50 microseconds.
The same limit should be applied to udelay().
Actually, udelay() should *never* been used.
It was broken in older kernels, and SpeedStep makes it unreliable with all
kernel versions.
Any no cheating with a loop around udelay()!
On Fri, 24 Nov 2000, Bogdan Costescu wrote:
> On Thu, 23 Nov 2000, Berkan Eskikaya wrote:
>
> > > What if the driver gets the MII registers address wrong ?
> > > So, can you try running 'mii-diag -p 24 eth1' ?
> > We'll there is a definite change; mii-diag now reports link beat, but
> > I still cannot ping anywhere.
...
> Well, I somehow expected that. Page 147 of the documentation says:
>
> "These auto-negotiation registers are accessed through the MII management
> interface using a PHY address (PHYAD) of 11000b" = 24.
The manual might report that the transceiver is at address 24, but we should
still scan. The chip supports external MII transceivers (e.g. for the
100baseT4 product), and even 3Com doesn't keep track of what designs are
using the chip.
Here are a few MII rules.
A plug-in transceiver, via a MII connector, should be at address 0.
On-board transceivers are addressed 1..31
The scan order is 1,2,..30,31, 0
A transceiver jumpered for address 0 should power up disconnected from the
data lines. The driver might need to explicitly disable the on-board
transceivers before activating the external one.
> In vortex_probe1(), if MII or NWAY is used, there is a search for the MII
> interfaces (there can be more than 1). Why this search suddenly doesn't
> work anymore, I don't know; Don, do you have any ideea ? Maybe the
> preamble confuses the interface ? Maybe some more checks are needed before
> saying "we have a valid MII interface at this PHYAD" ?
I don't know. I suspect that it's just a bug in the address matching
design. The 3Com people never see it because they have the luxury of
shipping a unique driver with each board type, and thus their driver doesn't
need to do a MII scan. When a vendor puts a 3Com chip on their own board,
they get to tweak the driver source as well.
We have to write drivers to support any board that might come out in the
next two years.
> A workaround can be a test for IS_TORNADO and always add one interface
> with PHYAD = 24, but this still leaves the other 2 (or 4 according to
> vortex-diag output) MII interfaces detected. Now I don't understand
> something: if there are several MII interfaces and they provide similar
> capabilities, how is one of them selected as being the one in use ?
Nominally we should use the lowest numbered transceiver.
I really don't like always using #24, but it looks as if we might have to
that with some boards. It shouldn't be based only on IS_TORNADO, since that
would break with 100baseT4 and 100baseFx boards. There are also HomePNA and
radio transceivers with MII interfaces that might someday show up connected
to 3Com chips.
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 Bogdan.Costescu@IWR.Uni-Heidelberg.De Sat, 25 Nov 2000 16:45:52 +0100 (CET)
Date: Sat, 25 Nov 2000 16:45:52 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3c905CX-TXM
On Fri, 24 Nov 2000, Donald Becker wrote:
> Yes, everyone please keep this in mind.
> Register polling should never go on longer than about 50 microseconds.
I fully agree, however I still can't imagine how to poll reliably.
Is there any way to get a precise measurement of time spent within a loop?
We can at least find out if there is a PCI problem (in which case I really
don't know what to do) or a NIC problem (if the time needed for completion
of the operation is much larger than specified in docs -> hardware bug ?).
Until now I think I was bitten by this "bug" because my cluster nodes
would suddenly die after 2-3 weeks of perfect functioning, while now with
the increased counts I run them happily for more than 2 months. But
waiting 2-3 weeks for an event to happen is a very unreliable way of
reproducing things for debugging. If Richard is able to produce it at
will, we might be able to get some more data easily.
> The manual might report that the transceiver is at address 24, but we should
> still scan. The chip supports external MII transceivers (e.g. for the
> 100baseT4 product), and even 3Com doesn't keep track of what designs are
> using the chip.
Sure, I didn't say "set it at 24 and that's all !".
> Here are a few MII rules.
> A plug-in transceiver, via a MII connector, should be at address 0.
> On-board transceivers are addressed 1..31
> The scan order is 1,2,..30,31, 0
> A transceiver jumpered for address 0 should power up disconnected from the
> data lines. The driver might need to explicitly disable the on-board
> transceivers before activating the external one.
These rules make sense to me. But is this an "official" standard or just
your experience derived from all the drivers that you've written?
> I don't know. I suspect that it's just a bug in the address matching
> design. ...
Is there any possibility that PCI problems affect the MDIO operations ?
After all, MDIO operations happen through the PCI bus....
> I really don't like always using #24, but it looks as if we might have to
> that with some boards. It shouldn't be based only on IS_TORNADO, since that
> would break with 100baseT4 and 100baseFx boards. There are also HomePNA and
> radio transceivers with MII interfaces that might someday show up connected
> to 3Com chips.
AFAIK, these are the first boards where scanning for MII interfaces fails.
Do you know of some others ?
What I wanted to say was "if this is Tornado, we _know_ that we have at
least one NWAY transceiver on-board, at PHYAD 24" (because the chip itself
carries it and AFAIK there is no possibility to disable it). After that we
start searching (eventually skipping 24, or purposedly looking for it as
some kind of check) and add all the others. Now you say that we should use
the lowest numbered transceiver; is this also a standard ?
If there is a requirement that phys[] is ordered, we can start with
phys[0]=24, then if we find another, we set phys[0]=x and phys[1]=24 and
so on, only moving 24 if one lower than it is found. But in
vortex_timer() only phys[0] is used; actually I cannot find anything
that treats more than one transceiver, except the scanning itself...
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Sun, 26 Nov 2000 18:24:18 +0100 (CET)
Date: Sun, 26 Nov 2000 18:24:18 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] MII Transceivers
Hi,
I have some questions and suggestions about MII transceiver handling.
Part 1: On-chip vs. external transceivers
For Cyclone, the on-chip transceiver is also at PHYAD 24 (p. 161).
The AutoSelect sequence (p. 213 for B, p. 193 for C) suggests that if
AutoNegotiate is set (in xcvrSelect, which we equate to XCVR_NWAY) only the
on-chip transceiver is to be taken into consideration. If we want to say
XCVR_NWAY means any (on-chip or not on-chip) transceiver that supports
autonegotiation (as this is different from 3Com's interpretation), we should
probably check for NWAY capabilities on the MII transceiver(s) that we find.
If we stay with 3Com's recommandations, we can split the code which now does:
(in vortex_probe1)
if (dev->if_port == XCVR_MII || dev->if_port == XCVR_NWAY)
into something like this:
if (dev->if_port == XCVR_NWAY) {
phys[0] = 24;
/* eventually some printk to say that it was found and its status */
}
else if (dev->if_port == XCVR_MII){
... <- here we have the current code
/* we can skip PHYAD 24 in scanning for Cyclone and Tornado as 3Com suggests;
probably only set phys[0]=24 if no other PHY is found or even report
no MII devices found if XCVR_MII is forced */
}
If I understood well, for the older cards XCVR_NWAY is illegal, so I guess
that we don't have to check for card type, only on the XCVR_MII branch if
we want to skip 24.
HomePNA or radio transceivers should be treated as XCVR_MII devices.
Part 2: Scanning for valid transceivers
1.) What is the meaning of
mdio_read(ioaddr, 24, 1);
just before the for loop used for scanning (in vortex_probe1) ?
2.) Upon entry in vortex_probe1 there is no reset of the card. Should we
try to reset the transceiver (setting bit 15 of Control register (MR0))
before checking the status ?
3.) The driver checks only for existence of up to 2 transceivers (that's the
size of the phys array). I guess that if we'd increase the size to 32, the CX
cards will report at least 31 available interfaces, with all but the one
at PHYAD 24 being set as in Berkan's report. This might mean that the on-chip
transceiver is responding to all PHYADs between 1 and 31 (maybe 0 too), but
only one instance is correctly set at start-up and it actually carries
meaningful info; maybe just to return some consistent data that is to be
replaced when another transceiver is instaled ?
Furthermore, according to their proposed AutoSelect sequence, these data are
only to be read when checking for XCVR_MII, so if we read them when checking
for XCVR_NWAY, we might do something "illegal" and the returned data is
simply bogus...
Part 3: MDIO operations
I know that Don said that the MDIO parts should not be touched, but...
1.) I don't understand the mdio_preamble_required handling. In vortex_probe1,
even for the on-chip transceiver (XCVR_NWAY), mdio_preamble_required is
non-zero (at least 2 x "++" and only one "--"). Why do we check for
mdio_preamble_required in mdio_[read,write] before calling mdio_sync?
Even more, if all transceivers require mdio_sync, why do we bother bother
updating mdio_preamble_required ?
2.) In mdio_read,
int read_cmd = (0xf6 << 10) | (phy_id << 5) | location;
which will generate an 18-bit field. Then, we only use the first 15 LSB
of it:
/* Shift the read command bits out. */
for (i = 14; i >= 0; i--) {
Is there a reason for the extra bits ?
3.) The MDIO timing is based on PCI timing. If the PCI timing is wrong for
some reason, MDIO operations would somehow be affected. I afraid especially
about mdio_delay() which is done as inl(mdio_addr)... Now, there is no
specification about extra reads from mdio_addr during the read/write frames.
How about disturbing the cycle by doing these extra 'in's ? (in case 3Com
decided to do things differently from what they did before...)
Hoping these might shed some light,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From benjaminlee@consultant.com Mon, 27 Nov 2000 14:07:31 +1100
Date: Mon, 27 Nov 2000 14:07:31 +1100
From: Benjamin Lee benjaminlee@consultant.com
Subject: [vortex] 3c905B high throughput transmit timeout
Hi all,
Transferring (transmitting) at high rates 8.5 - 10MBytes/s.
Using the driver:
3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others.
http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See
Documentation/networking/vortex.txt
eth2: 3Com PCI 3c905B Cyclone 100baseTx at 0xc800, 00:10:4b:66:d2:9f, IRQ 18
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 782d.
Enabling bus-master transmits and whole-frame receives.
eth3: 3Com PCI 3c905B Cyclone 100baseTx at 0xcc00, 00:10:4b:6a:4f:f5, IRQ 17
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 786d.
MII transceiver found at address 0, status 786d.
Enabling bus-master transmits and whole-frame receives.
eth2: using NWAY autonegotiation
eth3: using NWAY autonegotiation
Froze my:
Linux xaos.home.ben 2.4.0-test11 #10 SMP Sun Nov 19 02:17:17 EST 2000 i686
unknown
With the message:
Nov 19 18:07:15 xaos kernel: NETDEV WATCHDOG: eth2: transmit timed out
Nov 19 18:07:15 xaos kernel: eth2: transmit timed out, tx_status 00 status
e601.
Nov 19 18:07:15 xaos kernel: eth2: Interrupt posted but not delivered --
IRQ blocked by another device?
Nov 19 18:07:15 xaos kernel: Flags; bus-master 1, full 0; dirty
148334(14) current 148334(14).
I had to hard reset. ;-(
I took a look the documentation, and searched the web, where I found
something on how the card can receive too many collisions thus transmit can
block. This was relevant for 2.4.0test7, I was wondering if this is the same
problem and if it is supposed to have been fixed.
Also saw the patch from Andrew M.
I didn't apply the patch yet...
Having cranked up the logging setting in modules.conf, debug=7; the freeze
does not occur (yet).
When I transfer an ISO image, 650MB, I see kernel messages like this:
(Ignore the "APIC error on CPU0" errors, this is an infamous BP6
motherboard).
Nov 27 13:53:33 xaos kernel: <701
Nov 27 13:53:33 xaos kernel: eth2: Trying to send a packet, Tx index
66139.
Nov 27 13:53:37 xaos kernel: <
Nov 27 13:53:37 xaos kernel: <7d a packet, Tx index 67123.
Nov 27 13:53:37 xaos kernel: boomerang_start_xmit()
Nov 27 13:53:38 xaos kernel: Tx index 71651.
Nov 27 13:53:38 xaos kernel: bopt_xmit()
Nov 27 13:53:39 xaos kernel: <7xmit()
Nov 27 13:53:39 xaos kernel: <.
Nov 27 13:53:39 xaos kernel: to send a packet, Tx index 83952.
Nov 27 13:53:39 xaos kernel: <77>eth2: exiting interrupt, status e000.
Nov 27 13:53:39 xaos kernel: eth2: Trying to send a packet, Tx index
85091.
Nov 27 13:53:40 xaos kernel: 7>boomerang_start_xmit()
Nov 27 13:53:40 xaos kernel: ndex 90572.
Nov 27 13:53:40 xaos kernel: <7)
Nov 27 13:53:40 xaos kernel: ng to send a packet, Tx index 91212.
Nov 27 13:53:41 xaos kernel: tart_xmit()
Nov 27 13:53:41 xaos kernel: t, Tx index 95957.
Nov 27 13:53:41 xaos kernel: boomerang_rx
Nov 27 13:53:51 xaos kernel: <7tus 6000803c.
Nov 27 13:53:52 xaos kernel: < e201.
Nov 27 13:53:52 xaos kernel: <7e201, latency 6 ticks.
Nov 27 13:53:52 xaos kernel: <7 interrupt loop, status e201.
Nov 27 13:53:52 xaos kernel: boomerang_rx
Nov 27 13:53:54 xaos kernel: 401
Nov 27 13:53:54 xaos kernel: <7: Trying to send a packet, Tx index 198869.
Nov 27 13:53:54 xaos kernel: : Trying to send a packet, Tx index 198872.
Nov 27 13:53:54 xaos kernel: <7: Trying to send a packet, Tx index 198873.
Nov 27 13:53:54 xaos kernel: e401
Nov 27 13:53:54 xaos kernel: boomerang_start_xmit()
Nov 27 13:53:55 xaos kernel: <7send a packet, Tx index 209199.
Nov 27 13:53:55 xaos kernel: <7.
Nov 27 13:53:56 xaos kernel: eoet, Tx index 212063.
Nov 27 13:53:56 xaos kernel: g interrupt, status e000.
Nov 27 13:53:56 xaos kernel: <7x index 212632.
Nov 27 13:53:56 xaos kernel: x index 212633.
Nov 27 13:53:56 xaos kernel: n interrupt loop, status e401.
Nov 27 13:53:56 xaos kernel: <74190.
Nov 27 13:53:56 xaos kernel: packet, Tx index 242980.
Nov 27 13:54:00 xaos kernel: <7omerang_start_xmit()
Nov 27 13:54:00 xaos kernel: >eth2: Trying to send a packet, Tx index
244809.
Nov 27 13:54:00 xaos kernel: < packet, Tx index 246039.
Nov 27 13:54:00 xaos kernel: <7ing to send a packet, Tx index 246378.
Nov 27 13:54:00 xaos kernel: <77>eth2: Trying to send a packet, Tx index
248080.
Nov 27 13:54:00 xaos kernel: <77>eth2: Trying to send a packet, Tx index
2480817>eth2: Trying to send a packet, Tx index 2487>eth2: Trying to send a
packet, Tx index 24807>eth2: Trying to send a packet, Tx index 248084.
Nov 27 13:54:01 xaos kernel: <72: Trying to send a packet, Tx index 251160.
Nov 27 13:54:01 xaos kernel: <7x 251335.
Nov 27 13:54:02 xaos kernel: <72: interrupt, status e401, latency 5 ticks.
Nov 27 13:54:02 xaos kernel: <70803c.
Nov 27 13:54:02 xaos kernel: omerang_interrupt. status=0xe000
Nov 27 13:54:02 xaos kernel: boomerang_rx(): status e001
Nov 27 13:54:03 xaos kernel: ying to send a packet, Tx index 2696ying to
send a packet, Tx index 269607.ying to send a packet, Tx index 269608.
Nov 27 13:54:03 xaos kernel: eth2: Trying to send a packet, Tx index
282413.
Nov 27 13:54:05 xaos kernel: <7rying to send a packet, Tx index 282761.
Nov 27 13:54:05 xaos kernel: eth2: interrupt, status e201,
latencystatus e201.
Nov 27 13:54:13 xaos kernel: <7Tx index 350572.
Nov 27 13:54:13 xaos kernel:
> ...
>
> With the message:
>
> Nov 19 18:07:15 xaos kernel: NETDEV WATCHDOG: eth2: transmit timed out
> Nov 19 18:07:15 xaos kernel: eth2: transmit timed out, tx_status 00 status
> e601.
> Nov 19 18:07:15 xaos kernel: eth2: Interrupt posted but not delivered --
> IRQ blocked by another device?
This is probably the infamous APIC problem. Possibly the kernel
is missing an ACK to an interrupt. Possibly a hardware bug.
We don't know. As you can see, it's very rare.
> Nov 19 18:07:15 xaos kernel: Flags; bus-master 1, full 0; dirty
> 148334(14) current 148334(14).
hmm. No packets queued. That's odd.
> I had to hard reset. ;-(
That's odd as well. I suspect you're sharing IRQ18 with the
IDE controller? IDE doesn't like missed interrupts :(
Could you please send the output from `cat /proc/interrupts'?
From andrewm@uow.edu.au Mon, 27 Nov 2000 21:46:38 +1100
Date: Mon, 27 Nov 2000 21:46:38 +1100
From: Andrew Morton andrewm@uow.edu.au
Subject: [vortex] Richard's 3c905CX
This is the output from Richard Gooch's 3c905CX, using
kernel 2.4.0-test11.
It is essentially identical to Berkan's, yet Richard's driver
is finding the transceiver quiet happily.
So it would appear that some change to Donald's driver
since the 0.99H fork has caused these new NICs to play up.
BTW: why is the RxComplete interrupt enabled in 0.99Ra??
> vortex-diag -mm -v
===============================================================================
vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xb800.
Indication enable is 06c6, interrupt enable is 06ce.
No interrupt sources are pending.
Transceiver/media interfaces available: 100baseTx 10baseT.
Transceiver type in use: Autonegotiate.
MAC settings: full-duplex.
Station address set to 00:01:03:1f:33:20.
Configuration options 0052.
Parsing the EEPROM of a 3Com Vortex/Boomerang:
3Com Node Address 00:01:03:1F:33:20 (used as a unique ID only).
OEM Station address 00:01:03:1F:33:20 (used as the ethernet address).
Manufacture date (MM/DD/YYYY) 9/15/2000, division H, product HN.
Options: none.
Vortex format checksum is incorrect (0045 vs. 10b7).
Cyclone format checksum is incorrect (0xdf vs. 0xd3).
Hurricane format checksum is incorrect (0xf6 vs. 0xd3).
MII PHY found at address 1, status 0020.
MII PHY found at address 2, status 0020.
MII PHY found at address 3, status 0020.
MII PHY found at address 4, status 0020.
MII PHY 0 at #1 transceiver registers:
0000 0020 0000 0000 01e0 45e1 0003 0800
0000 0000 0000 0000 0000 0000 0000 0000
0600 c610 0000 4000 0000 0000 0000 0000
0000 0200 0000 0000 0000 0aee 0000 0000.
MII PHY 1 at #2 transceiver registers:
0000 0020 0000 0000 01e0 45e1 0003 0800
0000 0000 0000 0000 0000 0000 0000 0000
0600 c610 0000 4000 0000 0000 0000 0000
0000 0200 0000 0000 0000 0aee 0000 0000.
MII PHY 2 at #3 transceiver registers:
0000 0020 0000 0000 01e0 45e1 0003 0800
0000 0000 0000 0000 0000 0000 0000 0000
0600 c610 0000 4000 0000 0000 0000 0000
0000 0200 0000 0000 0000 0aee 0000 0000.
MII PHY 3 at #4 transceiver registers:
0000 0020 0000 0000 01e0 45e1 0003 0800
0000 0000 0000 0000 0000 0000 0000 0000
0600 c610 0000 4000 0000 0000 0000 0000
0000 0200 0000 0000 0000 0aee 0000 0000.
Here are Richard's boot messages:
# insmod 3c59x debug=7
3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
See Documentation/networking/vortex.txt
eth0: 3Com PCI 3c905C Tornado at 0xb800, 00:01:03:1f:33:20, IRQ 5
Internal config register is 1800000, transceivers 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 1, status 24.
MII transceiver found at address 2, status 24.
3c59x: Wake-on-LAN functions disabled
Enabling bus-master transmits and whole-frame receives.
===============================================================================
# ifconfig eth0 up; ping ...
eth0: Filling in the Rx ring.
eth0: using NWAY autonegotiation
eth0: Initial media type Autonegotiate.
vortex_up(): writing 0x1800000 to InternalConfig
eth0: MII #1 status 0024, link partner capability 45e1, setting full-duplex.
eth0: vortex_up() InternalConfig 01800000.
eth0: vortex_up() irq 5 media status 8080.
boomerang_start_xmit()
eth0: Trying to send a packet, Tx index 0.
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Mon, 27 Nov 2000 11:58:27 +0100 (CET)
Date: Mon, 27 Nov 2000 11:58:27 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] Richard's 3c905CX
On Mon, 27 Nov 2000, Andrew Morton wrote:
> It is essentially identical to Berkan's, yet Richard's driver
> is finding the transceiver quiet happily.
It doesn't look to me like finding the transceiver:
> > vortex-diag -mm -v
> MII PHY found at address 1, status 0020.
> MII PHY found at address 2, status 0020.
> MII PHY found at address 3, status 0020.
> MII PHY found at address 4, status 0020.
>
> Here are Richard's boot messages:
> MII transceiver found at address 1, status 24.
> MII transceiver found at address 2, status 24.
> eth0: MII #1 status 0024, link partner capability 45e1, setting full-duplex.
These are exactly like Berkan's. Also the product ID reported by
vortex-diag seems to be the same, although the manufacturing date is
8 days apart, so there might be a big lot coming...
I'm waiting for Don's reply, but IMHO the scheme with split XCVR_NWAY and
XCVR_MII detection is the only way to do it right.
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From ben@realthought.net Mon, 27 Nov 2000 22:20:32 +1100
Date: Mon, 27 Nov 2000 22:20:32 +1100
From: Benjamin Lee ben@realthought.net
Subject: [vortex] 3c905B high throughput transmit timeout
Hey Andrew,
Yup, it's definitely sharing interrupt 18.
So I guess I was only able to see the problem because I was accessing files
from ide2/3 and throwing them down eth2, eh? ;-O And it may be because I'm
running ATA66 stuff too. What an unfortunate combination. ;-P
[ben@xaos:/mnt/e/tmp]$ cat /proc/interrupts
CPU0 CPU1
0: 8994684 8749395 IO-APIC-edge timer
1: 36991 37003 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
5: 30043 31047 IO-APIC-edge soundblaster
8: 1 2 IO-APIC-edge rtc
9: 0 0 XT-PIC acpi
10: 13787 13447 IO-APIC-edge NE2000
12: 173620 180247 IO-APIC-edge PS/2 Mouse
14: 7 1 IO-APIC-edge ide0
15: 4 5 IO-APIC-edge ide1
16: 9235 9474 IO-APIC-level eth4
17: 139040 138217 IO-APIC-level eth3
18: 218622 216631 IO-APIC-level ide2, ide3, eth2
19: 40637 40879 IO-APIC-level eth1
NMI: 18101339 18101339
LOC: 17744268 17744270
ERR: 93
[Mon, 27 Nov 2000 22:16:07 +1100] Home Sweet Home
[ben@xaos:/mnt/e/tmp]$
On Mon, Nov 27, 2000 at 09:37:41PM +1100, Andrew Morton wrote:
> Benjamin Lee wrote:
> >
> > ...
> >
> > With the message:
> >
> > Nov 19 18:07:15 xaos kernel: NETDEV WATCHDOG: eth2: transmit timed out
> > Nov 19 18:07:15 xaos kernel: eth2: transmit timed out, tx_status 00 status
> > e601.
> > Nov 19 18:07:15 xaos kernel: eth2: Interrupt posted but not delivered --
> > IRQ blocked by another device?
>
> This is probably the infamous APIC problem. Possibly the kernel
> is missing an ACK to an interrupt. Possibly a hardware bug.
> We don't know. As you can see, it's very rare.
>
> > Nov 19 18:07:15 xaos kernel: Flags; bus-master 1, full 0; dirty
> > 148334(14) current 148334(14).
>
> hmm. No packets queued. That's odd.
>
> > I had to hard reset. ;-(
>
> That's odd as well. I suspect you're sharing IRQ18 with the
> IDE controller? IDE doesn't like missed interrupts :(
>
> Could you please send the output from `cat /proc/interrupts'?
--
__________________________________________________________________________
QOTD:
"I'd never marry a woman who didn't like pizza... I might play
golf with her, but I wouldn't marry her!"
From andrewm@uow.edu.au Mon, 27 Nov 2000 22:28:15 +1100
Date: Mon, 27 Nov 2000 22:28:15 +1100
From: Andrew Morton andrewm@uow.edu.au
Subject: [vortex] 3c905B high throughput transmit timeout
Benjamin Lee wrote:
>
> Hey Andrew,
>
> Yup, it's definitely sharing interrupt 18.
Ugh. I suggest you use the BIOS menus to increase the number of
interrupts which are allocated to PCI. Make sure your NIC
and IDE are not sharing the same interrupt. That way if
it happens again you won't crash and you won't screw your
filesystem. But you'll need to reboot to get the interrupts
back.
If it becomes a problem the only known fix is to boot with
the `noapic' LILO option. This will slow things down a little
because all interrupts go through the old 8259 to CPU0
only, but it doesn't seem to make a lot of difference.
From ben@realthought.net Mon, 27 Nov 2000 22:59:21 +1100
Date: Mon, 27 Nov 2000 22:59:21 +1100
From: Benjamin Lee ben@realthought.net
Subject: [vortex] 3c905B high throughput transmit timeout
I might try the LILO 'noapic' first. It seems to be the most popular
solution for several interrupt / APIC related bugs.
Thanks,
Ben.
On Mon, Nov 27, 2000 at 10:28:15PM +1100, Andrew Morton wrote:
> Benjamin Lee wrote:
> >
> > Hey Andrew,
> >
> > Yup, it's definitely sharing interrupt 18.
>
> Ugh. I suggest you use the BIOS menus to increase the number of
> interrupts which are allocated to PCI. Make sure your NIC
> and IDE are not sharing the same interrupt. That way if
> it happens again you won't crash and you won't screw your
> filesystem. But you'll need to reboot to get the interrupts
> back.
>
> If it becomes a problem the only known fix is to boot with
> the `noapic' LILO option. This will slow things down a little
> because all interrupts go through the old 8259 to CPU0
> only, but it doesn't seem to make a lot of difference.
--
__________________________________________________________________________
QOTD:
"I'd never marry a woman who didn't like pizza... I might play
golf with her, but I wouldn't marry her!"
From pabel@tabu.uni-bonn.de Tue, 28 Nov 2000 23:08:52 +0100
Date: Tue, 28 Nov 2000 23:08:52 +0100
From: Roland Pabel pabel@tabu.uni-bonn.de
Subject: [vortex] Can WOL Password be set ??
Hi,
ether-wake has this option :
-p Append the four or six byte password PW to the packet.
A password is only required for a few adapter types.
The password may be specified in ethernet hex format
or dotted decimal (Internet address)
But I could not find any mentioning of this password in the config
programs (pci-config, vortex-diag, mii-diag). I have got a 3Com 905C
"Tornado" network card. WOL works without a password, but can it be
set ?? I don't like the idea of everyone being able to
power up my computer at any time...just trusted people given the
password would be fine.
thanks
Roland
--
Jolt schmeckt immer: Morgens, Mittags, Nachmittags...schmeckt auch
Abends noch, da kann man dann Nachts zwar nicht schlafen, aber
irgendwas ist ja immer...
From becker@scyld.com Tue, 28 Nov 2000 18:27:20 -0500 (EST)
Date: Tue, 28 Nov 2000 18:27:20 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] Can WOL Password be set ??
On Tue, 28 Nov 2000, Roland Pabel wrote:
> ether-wake has this option :
> -p Append the four or six byte password PW to the packet.
> A password is only required for a few adapter types.
> The password may be specified in ethernet hex format
> or dotted decimal (Internet address)
>
> But I could not find any mentioning of this password in the config
> programs (pci-config, vortex-diag, mii-diag). I have got a 3Com 905C
> "Tornado" network card. WOL works without a password, but can it be
> set ??
No, the 3Com chips don't support a WOL password.
They do support a downloading a wake-up pattern. A packet that matches the
receive filter and the pattern is treated the same as a WOL magic packet.
The pattern is composed of a list of
skip-exactly-N-bytes/match-these-M-bytes
so it cannot be used to emulate a WOL Magic Packet with password.
> I don't like the idea of everyone being able to
> power up my computer at any time...just trusted people given the
> password would be fine.
Adding support for the alternate wake-up feature would not be difficult, but
it would be really ugly. The code to set up the chip is grungy, and the
pattern limitations are difficult to represent in a hardware independent
manner.
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 ruben@nutz.nl Wed, 29 Nov 2000 04:11:12 +0100
Date: Wed, 29 Nov 2000 04:11:12 +0100
From: ruben@nutz.nl ruben@nutz.nl
Subject: [vortex] Can WOL Password be set ??
On Tue, Nov 28, 2000 at 06:27:20PM -0500, Donald Becker wrote:
> No, the 3Com chips don't support a WOL password.
Which confirms my expectations.
Next thing: You're gonna tell me that one can broad- or multicast a magic
packet, so that an evil H4x00r can burn out the electrical system of a large
university by multicasting to all machines, and the inrush-current will take
care of the rest. Ping. ZAP!
Back to our regular, on topic discussions. :)
--
Ruben | Strategy:
| A long-range plan whose merit cannot be evaluated until sometime
| after those creating it have left the organization.
From becker@scyld.com Tue, 28 Nov 2000 23:42:42 -0500 (EST)
Date: Tue, 28 Nov 2000 23:42:42 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] Can WOL Password be set ??
On Wed, 29 Nov 2000 ruben@nutz.nl wrote:
> On Tue, Nov 28, 2000 at 06:27:20PM -0500, Donald Becker wrote:
>
> > No, the 3Com chips don't support a WOL password.
>
> Which confirms my expectations.
>
> Next thing: You're gonna tell me that one can broad- or multicast a magic
> packet, so that an evil H4x00r can burn out the electrical system of a large
> university by multicasting to all machines, and the inrush-current will take
> care of the rest. Ping. ZAP!
That's annoying, but not a real risk.
The risk is worse: some cards+motherboards can translate Ethernet to SMB
packets, and talk to the system management processor while the machine is
powered soft-off. The system management processor, in turn, can often do
things such as flash the BIOS. Cool, eh? That's what happens when
corporate IT managers tell IBM and Intel "I don't want to find each machine
to update the BIOS", and "What if they are turned off?"
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 schorr@hrzpub.tu-darmstadt.de Wed, 29 Nov 2000 10:16:51 +0100 (CET)
Date: Wed, 29 Nov 2000 10:16:51 +0100 (CET)
From: Tobias Schorr schorr@hrzpub.tu-darmstadt.de
Subject: [vortex] 0.99Qk - no warm reboot
Hello!
I updatetd my 3com driver from 0.99L (i think :) to 0.99Qk.
No I have the problem that I can not warm reboot my server. I get error
messages like "pci bus error" or so. It scrols so fast I can not even read
it. Cold booting is no problem and the server works fine.
I am using kernel 2.0.38 with SMP. The driver is compiled into the kernel.
Any ideas?
Bye ... Tobias
--
//// Realname: Tobias Schorr \\\\
//// E-Mail: schorr@hrz.tu-darmstadt.de \\\\
\\\\ IRCNICK: DuffyDuck ////
\\\\ URL: http://www.tu-darmstadt.de/~schorr/ ////
From mark.lubratt@indeq.com Wed, 29 Nov 2000 10:25:01 -0600
Date: Wed, 29 Nov 2000 10:25:01 -0600
From: Mark Lubratt mark.lubratt@indeq.com
Subject: [vortex] 3cSOHO100-Tx Speed Problem
I just bought a 3cSOHO100-Tx card and I'm installing it on my Linux box at
home. The Linux system is a ALR 6x6 Revolution with 128MB RAM and 6 PPro
200MHz. It is running RH6.0 with the SMP kernel (2.2.5-15). My network
uses a LinkSys 10/100 dual speed 5-port hub. The NIC is not in a PCI/ISA
shared slot.
While the chip seems to be a 3c76x, I downloaded the latest 3c59x driver
with pci-scan and other stuff from the Scyld website. I have compiled the
drivers as modules and placed the modules in initrd so that they get loaded
out of the boot RAM drive to allow time for negotiation.
When I power up the computer, the link comes up at 100Mbs (as indicated on
the status lights both on the hub and the NIC). It stays that way through
driver loading until the network is brought up. At that point, the system
downshifts to 10Mbs.
I used vortex-diag and that said the available media types were 100baseTx
and 10baseT, but that the card was using 10baseT. I tried usind
'vortex-diag -A 100baseTx' to no avail. I also used 'mii-diag eth0 -A
100baseTx'. Both didn't seem to work. I've also tried a different network
cable. Nothing seems to work.
Does anybody have any suggestions? I've looked through the vortex archives
and the most promising thread ended up being a bad cable.
Thanks!
Mark
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Wed, 29 Nov 2000 17:40:03 +0100 (CET)
Date: Wed, 29 Nov 2000 17:40:03 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3cSOHO100-Tx Speed Problem
On Wed, 29 Nov 2000, Mark Lubratt wrote:
> I just bought a 3cSOHO100-Tx card and I'm installing it ...
> I used vortex-diag and that said the available media types were 100baseTx
> and 10baseT, but that the card was using 10baseT. I tried usind
> 'vortex-diag -A 100baseTx' to no avail. I also used 'mii-diag eth0 -A
> 100baseTx'. Both didn't seem to work. I've also tried a different network
> cable. Nothing seems to work.
Can you send us the detection message from driver start-up, along with the
output from 'vortex-diag -v' and 'mii-diag -v' ?
Do you specify any module options, by any chance ?
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From pabel@tabu.uni-bonn.de Wed, 29 Nov 2000 18:20:37 +0100
Date: Wed, 29 Nov 2000 18:20:37 +0100
From: Roland Pabel pabel@tabu.uni-bonn.de
Subject: [vortex] Can WOL Password be set ??
>
>No, the 3Com chips don't support a WOL password.
[...]
So if this ain't possible, I guess that accessing the information
of the WOL-packet is neither possbile ? Especially knowing whether
the computer was powered up by the network card would be
important.
Since the magic packet generated by ether-wake includes
the hardware address of the sender it could be used to determine
whether the powerup was authorized (and then linux could log it and
power down again) or not.
possible?
Roland
From ruben@nutz.nl Wed, 29 Nov 2000 23:55:41 +0100
Date: Wed, 29 Nov 2000 23:55:41 +0100
From: ruben@nutz.nl ruben@nutz.nl
Subject: [vortex] 3cSOHO100-Tx Speed Problem
On Wed, Nov 29, 2000 at 10:25:01AM -0600, Mark Lubratt wrote:
> When I power up the computer, the link comes up at 100Mbs (as indicated on
> the status lights both on the hub and the NIC). It stays that way through
> driver loading until the network is brought up. At that point, the system
> downshifts to 10Mbs.
Please do realize that many *hubs*, even though they say to be 10/100,
support just *one* speed, and that in that case the lowest speed wins. IE:
You have five machines on your hub. One has a 509, the rest has 100Mbit
cards. All your machines will be forced to 10Mbit operations.
(For mixed speeds to work, the hub needs to have a per-port buffer.
Otherwise it cannot forward broadcast to ports running on a different speed
as the originating port.)
--
Ruben
| Main's Law:
| For every action there is an equal and opposite government program.
From becker@scyld.com Wed, 29 Nov 2000 20:20:01 -0500 (EST)
Date: Wed, 29 Nov 2000 20:20:01 -0500 (EST)
From: Donald Becker becker@scyld.com
Subject: [vortex] Can WOL Password be set ??
On Wed, 29 Nov 2000, Roland Pabel wrote:
> >No, the 3Com chips don't support a WOL password.
> [...]
>
> So if this ain't possible, I guess that accessing the information
> of the WOL-packet is neither possbile ? Especially knowing whether
> the computer was powered up by the network card would be
> important.
You can find out if the network card received a magic packet, but not
if it was the device that raised the PME (Power Management Event) signal.
You must check the card for a magic packet reception before loading the
driver. The PowerMgmtCtrl register is both in PCI configuration space and
at offset 0x7c in I/O space. Reading the register in I/O space might not
work, so I use the 'pci-config' program to read the PMEstatus bit (bit 15,
0x8000).
> Since the magic packet generated by ether-wake includes
> the hardware address of the sender it could be used to determine
> whether the powerup was authorized (and then linux could log it and
> power down again) or not.
> possible?
You can read the packet data out, but that involves using the chip before it
has been reset. Doing that is risky.
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 mark.lubratt@indeq.com Thu, 30 Nov 2000 09:45:52 -0600
Date: Thu, 30 Nov 2000 09:45:52 -0600
From: Mark Lubratt mark.lubratt@indeq.com
Subject: [vortex] 3cSOHO100-Tx Speed Problem
Here is the information you requested.
As I said before, the module is loaded from the initrd file during boot.
The linuxrc file in the ramdrive contains:
insmod aic7xxx
insmod pci-scan
insmod 3c59x
No options were used loading the modules.
The module startup detection message is:
Nov 29 16:23:24 bill-the-cat kernel:
http://www.scyld.com/network/vortex.html
Nov 29 16:23:24 bill-the-cat kernel: eth0: 3Com 3cSOHO100-TX Hurricane at
0xfc00, 00:01:02:c0:9f:8b, IRQ 10
Nov 29 16:23:24 bill-the-cat kernel: 8K byte-wide RAM 5:3 Rx:Tx split,
autoselect/Autonegotiate interface.
Nov 29 16:23:24 bill-the-cat kernel: MII transceiver found at address 24,
status 786d.
Nov 29 16:23:24 bill-the-cat kernel: MII transceiver found at address 0,
status 786d.
Nov 29 16:23:24 bill-the-cat kernel: Enabling bus-master transmits and
whole-frame receives.
At this point, the hub and NIC lights indicate 100Mbs. Then the boot
scripts start up the network (ifcfg-eth0) and the hub and NIC lights drop to
10Mbs.
vortex-diag -v says:
vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3Com 3cSOHO100-TX adapter at 0xfc00.
Indication enable is 06c6, interrupt enable is 06de.
No interrupt sources are pending.
Transceiver/media interfaces available: 100baseTx 10baseT.
Transceiver type in use: 10baseT.
MAC settings: half-duplex.
Station address set to 00:01:02:c0:9f:8b.
Configuration options 000a.
Parsing the EEPROM of a 3Com Vortex/Boomerang:
3Com Node Address 00:01:02:C0:9F:8B (used as a unique ID only).
OEM Station address 00:01:02:C0:9F:8B (used as the ethernet address).
Manufacture date (MM/DD/YYYY) 8/10/2000, division H, product CJ.
Options: none.
Vortex format checksum is incorrect (003c vs. 10b7).
Cyclone format checksum is correct (0xa1 vs. 0xa1).
Hurricane format checksum is correct (0xa1 vs. 0xa1).
MII PHY found at address 24, status 784d.
MII PHY found at address 0, status 784d.
MII PHY 0 at #24 transceiver registers:
3000 784d 0000 0000 01e1 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0080 0090 0000 0000 0005 2001 0000
0000 2040 07cf 1c11 0011 1000 0000 0000.
MII PHY 1 at #0 transceiver registers:
3000 784d 0000 0000 01e1 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0080 0090 0000 0000 0005 2001 0000
0000 2040 07cf 1c11 0011 1000 0000 0000.
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.
and mii-diag -v says:
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #24 transceiver registers:
3000 784d 0000 0000 01e1 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0080 0090 0000 0000 0005 2001 0000
0000 2040 07cf 1c11 0011 1000 0000 0000.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD
10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Your link partner does not do autonegotiation, and this transceiver type
does not report the sensed link speed.
at this point, I disabled the network startup scripts and performed a cold
boot (powered off the system).
The module loaded with the same detection method.
Before starting the network, vortex-diag -v says:
vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3Com 3cSOHO100-TX adapter at 0xfc00.
Indication enable is ffff, interrupt enable is ffff.
Interrupt sources are pending.
Interrupt latch indication.
Adapter Failure indication.
Tx Complete indication.
Tx Available indication.
Rx Complete indication.
Rx Early Notice indication.
Driver Intr Request indication.
Statistics Full indication.
DMA Done indication.
Download Complete indication.
Upload Complete indication.
DMA in Progress indication.
Command in Progress indication.
Transceiver/media interfaces available: 100baseT4 100baseTx 100baseFx
10baseT 10base2 AUI MII .
Transceiver type in use: undefined-15.
MAC settings: full-duplex, Large packets permitted, 802.1Q flow control,
VLT VLAN enabled.
Maximum packet size is 65535.
Station address set to ff:ff:ff:ff:ff:ff.
Configuration options ffff.
Parsing the EEPROM of a 3Com Vortex/Boomerang:
3Com Node Address FF:FF:FF:FF:FF:FF (used as a unique ID only).
OEM Station address ff:FF:FF:FF:FF:FF (used as the ethernet address).
Manufacture date (MM/DD/YYYY) 15/31/2027, division y, product yy.
Options: force full-duplex.
Vortex format checksum is incorrect (0000 vs. ffff).
Cyclone format checksum is incorrect (00 vs. 0xff).
Hurricane format checksum is incorrect (00 vs. 0xff).
***WARNING***: No MII transceivers found!
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.
and mii-diag -v says:
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #24 transceiver registers:
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff.
No MII transceiver present!.
Then I ran the network startup scripts and vortex-diag -v said:
vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3Com 3cSOHO100-TX adapter at 0xfc00.
Indication enable is 06c6, interrupt enable is 06de.
No interrupt sources are pending.
Transceiver/media interfaces available: 100baseTx 10baseT.
Transceiver type in use: 10baseT.
MAC settings: half-duplex.
Station address set to 00:01:02:c0:9f:8b.
Configuration options 000a.
Parsing the EEPROM of a 3Com Vortex/Boomerang:
3Com Node Address 00:01:02:C0:9F:8B (used as a unique ID only).
OEM Station address 00:01:02:C0:9F:8B (used as the ethernet address).
Manufacture date (MM/DD/YYYY) 8/10/2000, division H, product CJ.
Options: none.
Vortex format checksum is incorrect (003c vs. 10b7).
Cyclone format checksum is correct (0xa1 vs. 0xa1).
Hurricane format checksum is correct (0xa1 vs. 0xa1).
MII PHY found at address 24, status 784d.
MII PHY found at address 0, status 784d.
MII PHY 0 at #24 transceiver registers:
3000 784d 0000 0000 01e1 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0080 0090 0000 0000 0005 2001 0000
0000 2040 07cf 1c11 0011 1000 0000 0000.
MII PHY 1 at #0 transceiver registers:
3000 784d 0000 0000 01e1 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0080 0090 0000 0000 0005 2001 0000
0000 2040 07cf 1c11 0011 1000 0000 0000.
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.
and mii-diag -v said:
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #24 transceiver registers:
3000 784d 0000 0000 01e1 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0080 0090 0000 0000 0005 2001 0000
0000 2040 07cf 1c11 0011 1000 0000 0000.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD
10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Your link partner does not do autonegotiation, and this transceiver type
does not report the sensed link speed.
Thank you for your help, Bogdan!
If you need any other information, please let me know.
Sincerely,
Mark
-----Original Message-----
From: vortex-admin@scyld.com [mailto:vortex-admin@scyld.com]On Behalf Of
Bogdan Costescu
Sent: Wednesday, November 29, 2000 10:40 AM
To: Mark Lubratt
Cc: vortex@scyld.com
Subject: Re: [vortex] 3cSOHO100-Tx Speed Problem
On Wed, 29 Nov 2000, Mark Lubratt wrote:
> I just bought a 3cSOHO100-Tx card and I'm installing it ...
> I used vortex-diag and that said the available media types were 100baseTx
> and 10baseT, but that the card was using 10baseT. I tried usind
> 'vortex-diag -A 100baseTx' to no avail. I also used 'mii-diag eth0 -A
> 100baseTx'. Both didn't seem to work. I've also tried a different
network
> cable. Nothing seems to work.
Can you send us the detection message from driver start-up, along with the
output from 'vortex-diag -v' and 'mii-diag -v' ?
Do you specify any module options, by any chance ?
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
_______________________________________________
vortex mailing list
vortex@scyld.com
http://www.scyld.com/mailman/listinfo/vortex
From Bogdan.Costescu@IWR.Uni-Heidelberg.De Thu, 30 Nov 2000 17:23:41 +0100 (CET)
Date: Thu, 30 Nov 2000 17:23:41 +0100 (CET)
From: Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Subject: [vortex] 3cSOHO100-Tx Speed Problem
On Thu, 30 Nov 2000, Mark Lubratt wrote:
> Transceiver/media interfaces available: 100baseTx 10baseT.
> Transceiver type in use: 10baseT.
> MAC settings: half-duplex.
OK, so what you see using the lights is correct, it's working as 10baseT.
> Your link partner does not do autonegotiation, and this transceiver type
> does not report the sensed link speed.
This is strange. It means that the card couldn't get any info from the hub
about the supported speeds and in this case it is normal to fall back to
some "low performance" media type.
There are 2 things that might help you:
- run 'mii-diag -R' that resets the transceiver. Then run 'mii-diag -v'
again and if it gives again the message about not doing autonegotiation,
there is nothing more to do about autonegotiation.
- run 'mii-diag -F 100baseTx' to force setting media speed (but this is
really unrecommended); if this works, you can then add a module option to
force it at every boot
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From mark.lubratt@indeq.com Thu, 30 Nov 2000 10:27:07 -0600
Date: Thu, 30 Nov 2000 10:27:07 -0600
From: Mark Lubratt mark.lubratt@indeq.com
Subject: [vortex] 3cSOHO100-Tx Speed Problem
The hub reports my WinME box using the same NIC at 100Mbs. I can also
disconnect everything else from the hub and it still drops to 10Mbs when the
network comes up in the boot scripts.
Mark
-----Original Message-----
From: vortex-admin@scyld.com [mailto:vortex-admin@scyld.com]On Behalf Of
ruben@nutz.nl
Sent: Wednesday, November 29, 2000 4:56 PM
To: vortex@scyld.com
Subject: Re: [vortex] 3cSOHO100-Tx Speed Problem
On Wed, Nov 29, 2000 at 10:25:01AM -0600, Mark Lubratt wrote:
> When I power up the computer, the link comes up at 100Mbs (as indicated on
> the status lights both on the hub and the NIC). It stays that way through
> driver loading until the network is brought up. At that point, the system
> downshifts to 10Mbs.
Please do realize that many *hubs*, even though they say to be 10/100,
support just *one* speed, and that in that case the lowest speed wins. IE:
You have five machines on your hub. One has a 509, the rest has 100Mbit
cards. All your machines will be forced to 10Mbit operations.
(For mixed speeds to work, the hub needs to have a per-port buffer.
Otherwise it cannot forward broadcast to ports running on a different speed
as the originating port.)
--
Ruben
| Main's Law:
| For every action there is an equal and opposite government program.
_______________________________________________
vortex mailing list
vortex@scyld.com
http://www.scyld.com/mailman/listinfo/vortex
From mark.lubratt@indeq.com Thu, 30 Nov 2000 10:33:16 -0600
Date: Thu, 30 Nov 2000 10:33:16 -0600
From: Mark Lubratt mark.lubratt@indeq.com
Subject: [vortex] 3cSOHO100-Tx Speed Problem
I'll try these when I get home tonight.
One thing I forgot to mention is that I have the same card in my WinME
machine connected to the same hub. And the status lights indicate 100Mbs.
So, that card seems to do the negotiation and high speed stuff just fine.
This makes me think it's a driver issue instead of a hardware issue.
Sincerely,
Mark
-----Original Message-----
From: Bogdan Costescu [mailto:Bogdan.Costescu@IWR.Uni-Heidelberg.De]
Sent: Thursday, November 30, 2000 10:24 AM
To: Mark Lubratt
Cc: vortex@scyld.com
Subject: RE: [vortex] 3cSOHO100-Tx Speed Problem
This is strange. It means that the card couldn't get any info from the hub
about the supported speeds and in this case it is normal to fall back to
some "low performance" media type.
There are 2 things that might help you:
- run 'mii-diag -R' that resets the transceiver. Then run 'mii-diag -v'
again and if it gives again the message about not doing autonegotiation,
there is nothing more to do about autonegotiation.
- run 'mii-diag -F 100baseTx' to force setting media speed (but this is
really unrecommended); if this works, you can then add a module option to
force it at every boot
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
From sstoddar@gblx.net Thu, 30 Nov 2000 10:25:37 -0700
Date: Thu, 30 Nov 2000 10:25:37 -0700
From: Scott Stoddard sstoddar@gblx.net
Subject: [vortex] 3c556B adapters - and Slackware 7.1
Hi all! I am trying to compile the 3c59x-2.2.17+.gz driver for the 3c556B
adapter on Slackware 7.1, IBM T20 Thinkpad... I have tried the compile
command two ways this is the output I get
root@laptop:/win-c/linux/new# gcc -DMODULE -D__KERNEL__ -O6 -c
3c59x-2.2.17+.gz
gcc: 3c59x-2.2.17+.gz: linker input file unused since linking not done
root@laptop:/win-c/linux/new#
gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -c 3c59x-2.2.17+.gz
`[ -f /usr/src/linux/include/linux/modversions.h ] && echo -DMODVERSIONS`
gcc: 3c59x-2.2.17+.gz: linker input file unused since linking not done
root@laptop:/win-c/linux/new#
Can anyone suggest where I start to look for a fix? Thanx
--Scott