From bogdan.costescu@iwr.uni-heidelberg.de Wed, 2 May 2001 19:40:51 +0200 (CEST) Date: Wed, 2 May 2001 19:40:51 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? [ modified CC ] On Wed, 2 May 2001, Pekka Savola wrote: > > If yes, can you send me the identification message from the driver ? > > (including the first line with driver version). > > Apr 26 18:25:24 sampo kernel: 3c59x.c 18Feb01 Donald Becker and others > http://www.scyld.com/network/vortex.html > > 3c59x.c 18Feb01 Donald Becker and others > http://www.scyld.com/network/vortex.html > eth0: 3Com 3c905B Cyclone 100baseTx at 0xec00, 00:c0:4f:61:17:c9, IRQ 19 > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. > Media override to transceiver type 4 (100baseTX). > Enabling bus-master transmits and whole-frame receives. > eth0: Initial media type 100baseTX. > > Forced to 100/FD. > > As shipped with Red Hat Linux 6.2 errata kernel 2.2.19-6.2.1. > > This is nothing new, it has been plaguing for as long as I remember on > varying versions of kernel and drivers, at least a year. > > These are SMP Dell servers. The card is integrated on mobo. I guess that this is a special case. Maybe Don knows more about it... Anyway, the documentation that 3Com has on the web site specifically states that the MII interface on Cyclone chips is available at address 24. Maybe the chips that Dell uses are non-standard... Can you post output from lspci ? > Most other 3c905B|C cards here _usually_ show 10mbit / half-duplex with > mii-diag ("a null state"), even though they're really in 100/FD. Are these PCI cards or mobo-integrated chips ? Can you post output from lspci ? > Out of about 20-30 boxes, I could probably find one where 3c905B shows > anything correctly with mii-diag. You never reported to vortex or vortex-bug @scyld.com... > > Can you try 'mii-diag -p 24 eth0' ? > > [root@sampo log]$ mii-diag -p 24 > Using the default interface 'eth0'. > Using the specified MII PHY index 24. > Basic registers of MII PHY #24: ffff ffff ffff ffff ffff ffff ffff ffff. > No MII transceiver present!. Pfiuuu, I don't understand a thing... According with their docs, at 24 there should be a valid transceiver... 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 pekkas@netcore.fi Wed, 2 May 2001 21:28:39 +0300 (EEST) Date: Wed, 2 May 2001 21:28:39 +0300 (EEST) From: Pekka Savola pekkas@netcore.fi Subject: [vortex] Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? On Wed, 2 May 2001, Bogdan Costescu wrote: > On Wed, 2 May 2001, Pekka Savola wrote: > > > > If yes, can you send me the identification message from the driver ? > > > (including the first line with driver version). > > > > Apr 26 18:25:24 sampo kernel: 3c59x.c 18Feb01 Donald Becker and others > > http://www.scyld.com/network/vortex.html > > > > 3c59x.c 18Feb01 Donald Becker and others > > http://www.scyld.com/network/vortex.html > > eth0: 3Com 3c905B Cyclone 100baseTx at 0xec00, 00:c0:4f:61:17:c9, IRQ 19 > > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. > > Media override to transceiver type 4 (100baseTX). > > Enabling bus-master transmits and whole-frame receives. > > eth0: Initial media type 100baseTX. > > > > Forced to 100/FD. > > > > As shipped with Red Hat Linux 6.2 errata kernel 2.2.19-6.2.1. > > > > This is nothing new, it has been plaguing for as long as I remember on > > varying versions of kernel and drivers, at least a year. > > > > These are SMP Dell servers. The card is integrated on mobo. > > I guess that this is a special case. Maybe Don knows more about it... > Anyway, the documentation that 3Com has on the web site specifically > states that the MII interface on Cyclone chips is available at address 24. > Maybe the chips that Dell uses are non-standard... > > Can you post output from lspci ? Looking deeper into this, this appears partially a configuration error. The 100/FD forcing was done with 'options=4 full_duplex=1'. Then the output is as above. But shouldn't mii-diag -p 24 still work? Lspci output is: --- 00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] Subsystem: Dell Computer Corporation: Unknown device 0080 Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at ec00 Memory at fe101000 (32-bit, non-prefetchable) Expansion ROM at f8000000 [disabled] Capabilities: [dc] Power Management version 1 00: b7 10 55 90 17 01 10 02 00 00 00 02 08 40 00 00 10: 01 ec 00 00 00 10 10 fe 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 80 00 30: 00 00 00 f8 dc 00 00 00 00 00 00 00 0e 01 0a 0a --- However, there appears to be a problem with the driver with this specific chipset; if I change the forcing to 'options=8 full_duplex=1' as is proper, the mii-diag shows good: --- [root@lsampo /tmp]# ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #24: 3100 7809 0000 0000 0141 0080 0000 0000. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Your link partner is generating 100baseTx link beat (no autonegotiation). --- HOWEVER, network ceased to work immediately after I did this. So there appears to be a problem. With this unworking config, mii-diag shows: --- [root@sampo /tmp]# ./mii-diag -v mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. MII PHY #24 transceiver registers: 3100 7809 0000 0000 0141 0080 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Your link partner is generating 100baseTx link beat (no autonegotiation). MII PHY #24 transceiver registers: 3100 7809 0000 0000 0141 0080 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. This transceiver has no vendor identification. I'm advertising 0141: 100baseTx-FD 10baseT-FD Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0080: 100baseTx. Negotiation did not complete. --- The switch (Nortel Networks) is configured to 100/FD static. I just reproduced 100% this with with one other identical Dual Dell PC, with the same lspci. Running stock 2.2.19 kernel, with: 3c59x.c 18Feb01 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905B Cyclone 100baseTx at 0xec00, 00:c0:4f:61:30:1f, IRQ 19 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. Media override to transceiver type 4 (100baseTX). Enabling bus-master transmits and whole-frame receives. [Yeah, I know 100/FD forcing is bad; but I can't help it here :-( ] > > > Most other 3c905B|C cards here _usually_ show 10mbit / half-duplex with > > mii-diag ("a null state"), even though they're really in 100/FD. > > Are these PCI cards or mobo-integrated chips ? Can you post output from > lspci ? The ones that exhibited the above are probably all integrated. The same configuration error, 'options=4 full_duplex=1' has happened with with an external card too. It appears to be of newer revision. The difference here is that when you change to 'options=8 full_duplex=1', it actually _works_ too. lscpi: 00:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64) Subsystem: 3Com Corporation: Unknown device 9055 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at e000 Memory at fa000000 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 00: b7 10 55 90 17 00 10 02 64 00 00 02 08 20 00 00 10: 01 e0 00 00 00 00 00 fa 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 0a 0a 100% same kernel (non-smp system though). wrong config: [root@linset /root]# mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #0: 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x0000 ... 0000. Link status: not established. Link partner information information is not exchanged when in fixed speed mode. [root@linset /root]# vortex-diag -mm vortex-diag.c:v2.02 7/1/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0xe000. MII PHY found at address 24, status 7809. MII PHY 0 at #24 transceiver registers: 3000 780d 0040 6120 01e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0301 0000 0000 0000 0170 0100 0000 0037 000c 0f00 ff00 0027 0000 0000 000b. MII PHY #24 transceiver registers: 3000 780d 0040 6120 01e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0300 0000 0000 0000 01be 0200 0000 0037 000c 0f00 ff00 0027 0000 0000 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x780d ... 780d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:10:18:--:--:--, model 18 rev. 0. No specific information is known about this transceiver type. I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. corrected config, networking works on this card using these settings: [root@linset /root]# mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #24: 3000 7829 0040 6120 01e1 0081 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7829 ... 782d. Link status: previously broken, but now reestablished. Your link partner is generating 100baseTx link beat (no autonegotiation). > > Out of about 20-30 boxes, I could probably find one where 3c905B shows > > anything correctly with mii-diag. > > You never reported to vortex or vortex-bug @scyld.com... I took this as expected behaviour :/. --- I'm sorry for creating fuss with wrong configuration. I got it from '100BaseTx' from the source (perhaps there should be a note there!) _when_ options=8 didn't work. I hope there's enough debug information to gather why options=8 would appear to be failing on these dell mobo-integrated 3c905B's. HTH, Thanks, -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From bogdan.costescu@iwr.uni-heidelberg.de Wed, 2 May 2001 21:07:00 +0200 (CEST) Date: Wed, 2 May 2001 21:07:00 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? On Wed, 2 May 2001, Pekka Savola wrote: > The 100/FD forcing was done with 'options=4 full_duplex=1'. Then the > output is as above. But shouldn't mii-diag -p 24 still work? That's the problem. options=4 disables the MII/NWAY code, so that a MII transceiver is not looked for. mii-diag gets bogus data afterwards. > However, there appears to be a problem with the driver with this specific > chipset; if I change the forcing to 'options=8 full_duplex=1' as is > proper, the mii-diag shows good: Yes, options=8 enables NWAY support. However, in this case, full_duplex is invalid as autonegotiation implies "no forcing". I guess that this combination of options should be forbiden. > The switch (Nortel Networks) is configured to 100/FD static. That's the second part of the problem. The autonegotiation only works if _both_ ends of the connection use it. So you can either use autonegotiation at both ends or force both ends. If you would turn on autonegotiation on the switch and insmod 3c59x without any options, things should work as expected. [ I have here a BayStack 350/24 which works flawlesly with 905B/C cards. ] > [Yeah, I know 100/FD forcing is bad; but I can't help it here :-( ] If the switch settings cannot be changed (for administrative or whatever reason), you're stuck. But then why do you need mii-diag to work ? All it can report would be 100/FD. > The difference here is that when you change to 'options=8 full_duplex=1', > it actually _works_ too. > ... > Link status: previously broken, but now reestablished. > Your link partner is generating 100baseTx link beat (no > autonegotiation). No ideea why... this transceiver seems to work even when the remore end is not autonegotiating. > I took this as expected behaviour :/. 8-) > I'm sorry for creating fuss with wrong configuration. No problem! You're not the first one... 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 pekkas@netcore.fi Wed, 2 May 2001 22:44:23 +0300 (EEST) Date: Wed, 2 May 2001 22:44:23 +0300 (EEST) From: Pekka Savola pekkas@netcore.fi Subject: [vortex] Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ? On Wed, 2 May 2001, Bogdan Costescu wrote: > > However, there appears to be a problem with the driver with this specific > > chipset; if I change the forcing to 'options=8 full_duplex=1' as is > > proper, the mii-diag shows good: > > Yes, options=8 enables NWAY support. However, in this case, full_duplex is > invalid as autonegotiation implies "no forcing". I guess that this > combination of options should be forbiden. No. I talked with Don Becker about this two weeks ago. He said this is the recommended configuration for forcing 100/FD. As there is no way to disable auto-negotiation on 3c905B, we only force Full Duplex and let the link speed, forced by the switch, define the 100 (and support FD). I think that was the reasoning. --- [me] > But how do you force _100_/FD on 3c905B or 3c905C? You have to select 8 > and using mii-diag switch it on -- seems rather difficult procedure? Or > is there some other way? [Don] If the other end is set to forced full duplex, you can use 0x208. The chip will still have autonegotiation enabled, but the other end will just present 100baseTx link beat. The 0x200 setting will force the chip to full duplex. --- > > The switch (Nortel Networks) is configured to 100/FD static. > > That's the second part of the problem. The autonegotiation only works if > _both_ ends of the connection use it. So you can either use > autonegotiation at both ends or force both ends. If you would turn on > autonegotiation on the switch and insmod 3c59x without any options, things > should work as expected. Yes. I'm not trying to use autonegotiation. I'm trying to set static 100/FD. However, I'd like mii-diag/vortex-diag to be able to reliably detect which options you're using. Certain people have pressured a company policy to be forced 100/FD in LAN's where servers are connected, so autoneg is not possible. > If the switch settings cannot be changed (for administrative or whatever > reason), you're stuck. But then why do you need mii-diag to work ? All it > can report would be 100/FD. Being able to report: 1) whether auto-neg is being used 2) if static configuration is used, does it really work, is the speed what you expect? etc. With 3c905B's, perhaps related, there have also been problems with cards where you've set 100/FD forcing with 3com's DOS driver disk; then you could not use autonegotiation reliably. I _think_ it was like: 1) see that there is 100/FD set with dos disk 2) poweroff computer. boot it with options=4 full_duplex=1 in conf.modules 3) ifdown eth0 ; rmmod 3c59x 4) remove options line entirely from conf.modules 5) reload the driver with modprobe 3c59x; ifup eth0 Autonegotiation would not work, until after you have powered off the computer. I wonder if this seems familiar? HTH, Thanks, -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From jas@psfc.mit.edu Fri, 04 May 2001 15:07:57 -0400 Date: Fri, 04 May 2001 15:07:57 -0400 From: Joshua Stillerman jas@psfc.mit.edu Subject: [vortex] Using WOL for other purposes... Does anyone know how to enable the WOL function of a 3c905C-TX card regardless of the CPU/powersupply/bus state? I am hoping to implement a 'Reset on Lan' function by attaching the WOL signal to the reset switch of the computer via a relay. (On my PRIVATE NETWORK!) I am trying to do this in a way that does not depend on the state (happiness) of the operating system running on the computer. Any suggestions will be greatly appreciated. Thanks, Josh From becker@scyld.com Fri, 4 May 2001 17:56:11 -0400 (EDT) Date: Fri, 4 May 2001 17:56:11 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] Using WOL for other purposes... On Fri, 4 May 2001, Joshua Stillerman wrote: > Does anyone know how to enable the WOL function of a 3c905C-TX card > regardless of the CPU/powersupply/bus state? I am hoping to implement a > 'Reset on Lan' function by attaching the WOL signal to the reset switch > of the computer via a relay. (On my PRIVATE NETWORK!) I am trying to do > this in a way that does not depend on the state (happiness) of the > operating system running on the computer. Nope, can't be done. If it could be done, the cluster people would be all over it. The WOL circuitry is only enabled when the chip is set to ACPI D3-warm state. When the card is configured to receive normal packet it's in D0 state. The only way to do what you want is with a management co-processor on the motherboard connected by a System Management Bus to a special version of the 3c905C card that has a SMBus connector. 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 agburns@bellsouth.net Sun, 06 May 2001 16:31:39 -0400 Date: Sun, 06 May 2001 16:31:39 -0400 From: agburns@bellsouth.net agburns@bellsouth.net Subject: [vortex] 3c905B configuration problem My nic is a 3com 3c905B-TX integrated on the motherboard. The reports from boot up loading the module, the mii-diag report and my linksys router do not jive with each other. At boot it recognizes the 3c905B and states it is a 100TX interface. Then the mii-diag says that auto-negiotate is not enabled and the nic is runing at 10 Mbps, half duplex. If I set any of the media options, it will not have any effect on this report. The only way to get the full duplex and 100mbps lights on my router to light up is to set " options=1 " Which is AUI and is stated so at boot up when loading the 3c59x module. I don't know how to test the actual speed of my nic other than pinging a pc on the network. the options=1 setting gives me the best response rate, 0.2 ms vs 0.3 ms. Similar response with ping -f, But it bothers me that the module is telling me I running at 10 mbps. My linksys uses switches so I should be set at full_duplex, but everyone says that auto-negotiate is the preferred method. Should I be testing the network differently and why the conflicting info. Why doesn't options=8 full_duplex=1 do the trick? Any help will be appreciated. Running on Dell Optiplex - Intel PII - Slackware 7.1 - using the 3c59x that was packaged with Slakware. kernel 2.2.16 3c905B-TX integrated on motherboad Thanks Anthony From koos@kzdoos.xs4all.nl Mon, 7 May 2001 00:10:36 +0200 Date: Mon, 7 May 2001 00:10:36 +0200 From: Koos van den Hout koos@kzdoos.xs4all.nl Subject: [vortex] 3c595 'Transmit error, Tx status register 90' revisited --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline After I ran into the aforementioned error again (bigtime) I decided to google for other reports of this error. I have mentioned it to this list before, we never got anything better out of it then 'yes, this is a problem'. Searching the archives of this list with google gives a *lot* of reports for this error http://www.google.com/search?hl=en&lr=&safe=off&q=+site:www.scyld.com+Transmit+error,+Tx+status+register+3c595 Anyway, I found: http://www.scyld.com/pipermail/vortex-bug/1999-August/000524.html which suggests a somewhat crude patch which changes the location of the reset of the card. I tried to implement this patch in the 2.2.19 driver, which required some big adjustments because the structure of the driver has changed quite a lot. Anyway, hand-editing stuff worked. With the updated version, I still get the eth0: Transmit error, Tx status register 90. in my logs, it just recovers faster and continues. Patch attached. Because this is probably very specific to the 3c595 (and maybe only certain versions) I do not recommend adding it to the standard driver, but as a quickfix until a better networkcard is found[1] it works. [1] any opinions about the Netgear FA311/FA312 which you would like to mail me ? Koos van den Hout -- Koos van den Hout, PGP keyid RSA/1024 0xCA845CB5 via keyservers koos@kzdoos.xs4all.nl or DSS/1024 0xF0D7C263 -?) Fax +31-30-2817051 Visit my site about books with reviews /\\ http://idefix.net/~koos/ http://www.virtualbookcase.com/ _\_V --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="3c595-suh-hack-reset.patch" --- 3c59x.c.orig Sun May 6 23:25:02 2001 +++ 3c59x.c Sun May 6 23:39:12 2001 @@ -531,6 +531,17 @@ u16 capabilities, info1, info2; /* Various, from EEPROM. */ u16 advertising; /* NWay media advertisement */ unsigned char phys[2]; /* MII device addresses. */ + +#define SUH_HACK +/* +** I think that tx_reset should be done outside of the interrupt. +** If you network is jammed during heavy load and syslog shows +** "Transmit error" message, pls try me. +*/ +#ifdef SUH_HACK + /* tx_reset seems to be done outside of interrupt. */ + u16 tx_need_reset; +#endif u16 deferred; /* Resend these interrupts when we * bale from the ISR */ spinlock_t lock; @@ -1515,22 +1526,46 @@ } } if (do_tx_reset) { +#ifndef SUH_HACK wait_for_completion(dev, TxReset); outw(TxEnable, ioaddr + EL3_CMD); if (!vp->full_bus_master_tx) { clear_bit(0, (void*)&dev->tbusy); mark_bh(NET_BH); } +#else + vp->tx_need_reset=1; } } +static void vortex_tx_reset(struct device *dev) +{ + struct vortex_private *vp = (struct vortex_private *)dev->priv; + long ioaddr = dev->base_addr; + + wait_for_completion(dev, TxReset); + outw(TxEnable, ioaddr + EL3_CMD); + if (!vp->full_bus_master_tx) { + clear_bit(0, (void*)&dev->tbusy); + mark_bh(NET_BH); + } +} +#endif + static int vortex_start_xmit(struct sk_buff *skb, struct device *dev) { struct vortex_private *vp = (struct vortex_private *)dev->priv; long ioaddr = dev->base_addr; +#ifdef SUH_HACK + if (vp->tx_need_reset) { + vp->tx_need_reset = 0; + vortex_tx_reset(dev); + return 1; + } +#endif if (test_and_set_bit(0, (void*)&dev->tbusy) != 0) { if (jiffies - dev->trans_start >= TX_TIMEOUT) vortex_tx_timeout(dev); --+HP7ph2BbKc20aGI-- From andrewm@uow.edu.au Mon, 07 May 2001 13:34:09 +1000 Date: Mon, 07 May 2001 13:34:09 +1000 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c595 'Transmit error, Tx status register 90' revisited Koos van den Hout wrote: > > After I ran into the aforementioned error again (bigtime) I decided to > google for other reports of this error. I have mentioned it to this list > before, we never got anything better out of it then 'yes, this is a > problem'. hmm... So basically your're getting a storm of Tx underrun errors, and resetting the transmitter in the Tx interrupt routine is causing some sort of problem? I don't understand *why* it causes a problem - the transmitter has been stopped. Deferring the reset until start_xmit in this way will mean that any additional queued frames will sit in memory for an arbitrary amount of time - they won't be kicked off until higher-level code tries another transmit. Normally not a problem, but it could cause long delays in some workloads. The core question is: why are you getting Tx underrun errors? Any ideas? From andrewm@uow.edu.au Mon, 07 May 2001 13:34:03 +1000 Date: Mon, 07 May 2001 13:34:03 +1000 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c905B configuration problem agburns@bellsouth.net wrote: > > My nic is a 3com 3c905B-TX integrated on the motherboard. The reports from > boot up loading the module, the mii-diag report and my linksys router do > not jive with each other. > > At boot it recognizes the 3c905B and states it is a 100TX interface. Then > the mii-diag says that auto-negiotate is not enabled and the nic is runing > at 10 Mbps, half duplex. If I set any of the media options, it will not > have any effect on this report. > > The only way to get the full duplex and 100mbps lights on my router to > light up is to set " options=1 " Which is AUI and is stated so at boot up > when loading the 3c59x module. I don't know how to test the actual speed > of my nic other than pinging a pc on the network. the options=1 setting > gives me the best response rate, 0.2 ms vs 0.3 ms. Similar response with > ping -f, But it bothers me that the module is telling me I running at 10 > mbps. My linksys uses switches so I should be set at full_duplex, but > everyone says that auto-negotiate is the preferred method. > The handling of this stuff was a little confused in the 2.2.16 driver - the user's attempt to override things on the insmod command line tended to get overridden by the driver! I suspect that if you take the 2.2.19 driver all will be sweet. However, if your NIC's EEPROM is correctly set up then none of this is necessary. I bet you EEPROM isn't selecting autonegotiation. If you can, grab 3com's DOS-based setup tool from ftp://ftp.3com.com/pub/nic/3c90x/3c90xx2.exe and check those EEPROM settings. Please let us know the outcome. Thanks. From agburns@bellsouth.net Mon, 07 May 2001 18:13:16 -0400 Date: Mon, 07 May 2001 18:13:16 -0400 From: agburns@bellsouth.net agburns@bellsouth.net Subject: [vortex] 3c905B configuration problem Thanks You were right, the EEPROM was set to half_duplex. I use the DOS 3COM utility to configure and the nic lights up my linksys router and the vortex-diag and mii-diag report all as would be expected. Thanks Anthony At 01:34 PM 5/7/01 +1000, Andrew Morton wrote: >agburns@bellsouth.net wrote: > > > > My nic is a 3com 3c905B-TX integrated on the motherboard. The reports from > > boot up loading the module, the mii-diag report and my linksys router do > > not jive with each other. > > > > At boot it recognizes the 3c905B and states it is a 100TX interface. Then > > the mii-diag says that auto-negiotate is not enabled and the nic is runing > > at 10 Mbps, half duplex. If I set any of the media options, it will not > > have any effect on this report. > > > > The only way to get the full duplex and 100mbps lights on my router to > > light up is to set " options=1 " Which is AUI and is stated so at boot up > > when loading the 3c59x module. I don't know how to test the actual speed > > of my nic other than pinging a pc on the network. the options=1 setting > > gives me the best response rate, 0.2 ms vs 0.3 ms. Similar response with > > ping -f, But it bothers me that the module is telling me I running at 10 > > mbps. My linksys uses switches so I should be set at full_duplex, but > > everyone says that auto-negotiate is the preferred method. > > > >The handling of this stuff was a little confused in the 2.2.16 >driver - the user's attempt to override things on the insmod >command line tended to get overridden by the driver! > >I suspect that if you take the 2.2.19 driver all will be sweet. > >However, if your NIC's EEPROM is correctly set up then none >of this is necessary. I bet you EEPROM isn't selecting >autonegotiation. If you can, grab 3com's DOS-based setup >tool from ftp://ftp.3com.com/pub/nic/3c90x/3c90xx2.exe and >check those EEPROM settings. > >Please let us know the outcome. Thanks. From agburns@bellsouth.net Mon, 07 May 2001 21:27:13 -0400 Date: Mon, 07 May 2001 21:27:13 -0400 From: agburns@bellsouth.net agburns@bellsouth.net Subject: [vortex] two transceivers found My nic is working just fine, but i am curious to the meaning of the following from the vortex-diag -m report. I only have one nic installed, does this imply that it sees the same nic twice or this the 2.2.16 kernel bug vs the loaded module. MII PHY found at address 24, status 786d MII PHY found at address 0. status 786d MII PHY 0 at #24 transceiver registers: 3000 786d 0000 0000 45e1 0005 2801 0000 0000 0000 0000 0000 0000 0000 8000 0008 0000 0000 0005 2001 0000 0001 2042 1c11 0002 1000 0000 0000 MII PHY 1 at #0 transeiver registers: 3000 786d 0000 0000 45e1 0005 2801 0000 0000 0000 0000 0000 0000 0000 8000 0008 0000 0000 0005 2001 0000 0001 2042 1c11 0002 1000 0000 0000 Thanks Anthony From bogdan.costescu@iwr.uni-heidelberg.de Tue, 8 May 2001 10:25:09 +0200 (CEST) Date: Tue, 8 May 2001 10:25:09 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] two transceivers found On Mon, 7 May 2001 agburns@bellsouth.net wrote: > My nic is working just fine, but i am curious to the meaning of the > following from the vortex-diag -m report. > I only have one nic installed, does this imply that it sees the same nic > twice or this the 2.2.16 kernel bug vs the loaded module. > > MII PHY found at address 24, status 786d > MII PHY found at address 0. status 786d Partly hardware fault, partly driver fault. -Hardware: one should expect that the transceiver answers only on one address. However, many recent cards answer on 2 addresses. -Driver: the docs specify that for recent cards (like yours) there is always a transceiver at address 24. As the driver can only handle one transceiver, it would be logical to first test for address 24 then test all the others. Recent drivers (IIRC, from 2.2.19) do this, however, yours (from 2.2.16) doesn't - it just goes from 0 upwards. 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 thomas.symul@rd.francetelecom.fr Tue, 15 May 2001 19:19:14 +0200 Date: Tue, 15 May 2001 19:19:14 +0200 From: SYMUL Thomas FTRD/DTD/BAG thomas.symul@rd.francetelecom.fr Subject: [vortex] 3com 900B not working with mandrake 8.0 (kernel 2.4.3) Hi, I can't manage to make my 3COM 900B card working with mandrake 8.0 ( Kernel 2.4.3). It seems that the pb comes from the 900B card sharing the same IRQ that my video card. I've tried to change the IRQ assignation in modules.conf, or with linuxconf, but it reports me an error during boot time (whatever is the free irq i try to assign to the ethernet card). I also tried the 3c90x driver but it neither doesn't work. What's surprising me is that I never had any problem with 2.2.x Kernels, and it works fine under win 98. Thx in advance for your answers ... Best regards Thomas Symul From bogdan.costescu@iwr.uni-heidelberg.de Tue, 15 May 2001 20:00:03 +0200 (CEST) Date: Tue, 15 May 2001 20:00:03 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3com 900B not working with mandrake 8.0 (kernel 2.4.3) On Tue, 15 May 2001, SYMUL Thomas FTRD/DTD/BAG wrote: > I can't manage to make my 3COM 900B card working with mandrake 8.0 ( Kernel > 2.4.3). What are the problems ? Any error message in the logs ? > It seems that the pb comes from the 900B card sharing the same IRQ that my > video card. This is not necessarily a bad thing, Linux drivers are supposed to be able to share interrupts without problems. However, if you still have PCI slots available, you might want to move around the network card (assuming that the video card is AGP and cannot be moved) - this might change the IRQ the network card is assigned, so that it will have an interrupt line by its own. > I've tried to change the IRQ assignation in modules.conf, or > with linuxconf, but it reports me an error during boot time (whatever is the > free irq i try to assign to the ethernet card). Where did you get the information that it can be changed like that ? Specifying an "irq" module option is valid only for ISA cards. PCI cards get interrupts assigned by the PCI subsystem, which you cannot control this way. > I also tried the 3c90x driver but it neither doesn't work. Did you actually manage to compile the 3c90x driver ? AFAIK it's 2.2 only! 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 madmatt@bits.bris.ac.uk Wed, 16 May 2001 01:28:27 +0100 (BST) Date: Wed, 16 May 2001 01:28:27 +0100 (BST) From: Matt madmatt@bits.bris.ac.uk Subject: [vortex] 3c980tx problems I have a 3c980tx in a Dual PPro box, running 2.2.19-smp. It's hooked up to a switch with a mixture of other devices, (10base JetDirect, another hub, etc.). If I try to ping anything from this box, say 50 times, I will always lose at least 5% of the packets, from any other box to another device, no problem. The driver correctly negotiates to the switch, enabling 100base and Full-Duplex, I've replaced the cable three times with no effect and I've rejigged the card so it's not near any other PCI cards such that I don't have a clue what else to try now. I've compiled both mii-diag and vortex-diag, and these seem to work and report the autonegotiation. I can post the output of these if it's any help. The card seems to work fine apart from it just drops packets :( Any ideas appreciated Matt From sysadmin@disnet.demon.nl Wed, 16 May 2001 21:34:49 +0200 Date: Wed, 16 May 2001 21:34:49 +0200 From: sysadmin@disnet.demon.nl sysadmin@disnet.demon.nl Subject: [vortex] 3com 3c905C card gives troubles hi, Just installed a 3Com 3c905CX (the linux kernel says it's a 3c905C in syslog). The following trouble occurs: 1. card initialization seems fine (syslog-lines bleow) 2. setup with ip-addressing is fine so is the firewall/routing stuff 3. ifconfig seems it up, but there only is a TX-count >0 while the RX-count stays 0, no overruns collitions or errors The card is connected to your evarge cheap 10base-T hup. Sinc afaik the card is autoswitching (syslog confirms this), it should work fine. Also the leds on the hub and the card are on. oh yes, the cable is tested and okay. Now what can be wrong here? syslog: May 16 19:18:09 gateway kernel: 3c59x.c 16Aug00 Donald Becker and others http:// www.scyld.com/network/vortex.html May 16 19:18:09 gateway kernel: eth0: 3Com 3c905C Tornado at 0x6200, 00:01:02:f c:1d:66, IRQ 10 May 16 19:18:09 gateway kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/A utonegotiate interface. May 16 19:18:09 gateway kernel: MII transceiver found at address 24, status 78 09. May 16 19:18:09 gateway kernel: Enabling bus-master transmits and whole-frame receives. end ifconfig: eth0 Link encap:Ethernet HWaddr 00:01:02:FC:1D:66 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:362 errors:0 dropped:0 overruns:0 carrier:186 collisions:0 end Any help and/or suggestions are welcom. If you can, please CC htem to me as well. thanx, Andor Demarteau sysadmin From andrewm@uow.edu.au Thu, 17 May 2001 15:50:32 +1000 Date: Thu, 17 May 2001 15:50:32 +1000 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3com 3c905C card gives troubles sysadmin@disnet.demon.nl wrote: > > hi, > Just installed a 3Com 3c905CX (the linux kernel says it's a 3c905C in syslog). > The following trouble occurs: > 1. card initialization seems fine (syslog-lines bleow) > 2. setup with ip-addressing is fine so is the firewall/routing stuff > 3. ifconfig seems it up, but there only is a TX-count >0 while the RX-count stays 0, no overruns collitions or errors It sounds like you have a new 3c905CX. Timing changes in the hardware made the driver stop working. It sends, but it won't receive. You're using 2.2 kernels? You should use the driver in 2.2.19. From Reiner.Suikat@dlr.de Thu, 17 May 2001 09:57:02 +0200 Date: Thu, 17 May 2001 09:57:02 +0200 From: Suikat, Reiner Reiner.Suikat@dlr.de Subject: [vortex] Slow connection in local domain Hello, I'm experiencing a strange problem with Linux on my laptop. Any connection within the local domain is extremely slow (< 5kB/sec), anything going outside is normal (up to 200kB/sec). Some information about my machine and setup: HW: Toshiba Portege 7140CT with Network Dock II (ethernet onboard in the docking station) SW: Redhat 7.1 with SGI XFS (SGI's XFS-1.0 RedHat installer CD) (Kernel upgraded to 2.4.4, but problem was in the original 2.4.2 kernel also) Startup Messages from 3c59x driver: May 17 09:27:13 beetlejuice kernel: eth0: 3Com PCI 3c905C Tornado at 0xfb00, 00:00:39:71:33:24, IRQ 11 May 17 09:27:13 beetlejuice kernel: product code 0000 rev 00.11 date 00-00-00 May 17 09:27:13 beetlejuice kernel: Full duplex capable May 17 09:27:13 beetlejuice kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. May 17 09:27:13 beetlejuice kernel: MII transceiver found at address 24, status 782d. May 17 09:27:13 beetlejuice kernel: Enabling bus-master transmits and whole-frame receives. May 17 09:27:13 beetlejuice kernel: eth0: scatter/gather enabled. h/w checksums enabled May 17 09:27:13 beetlejuice kernel: eth0: using NWAY device table, not 8 Output from ifconfig eth0: eth0 Linkverkapselung:Ethernet HWaddr 00:00:39:71:33:24 inet addr:129.247.35.172 Bcast:129.247.47.255 Maske:255.255.240.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Empfangene Pakete:8427 Fehler:3 Weggeworfen:0 Überlauf:0 Rahmen:6 Verschickte Packete:18 Fehler:0 Weggeworfen:0 Überlauf:0 Rahmen:0 Kollisionen:0 Sendewarteschlangenlänge:100 Interrupt:11 Basisadresse:0xfb00 The network setup (own ip, netmask, router and name server) is correct for our local net. There are no error messages in the message log file, not even with debug=6 set for the driver. The same machine running under Windows 2000 achieves almost the full 10MB/sec on our local net. BTW, Win2000 reports a 3C920 (3C905-TX compatible) network adapter. I have no idea how to debug the problem. Does anyone on this list have a clue what could be causing this or what are sensible steps to find out? Thanks for any help you can provide Reiner -- German Aerospace Center (DLR) Institute of Flight Guidance Dr.-Ing. Reiner Suikat Tel: (49) 531-295-2552 Fax: (49) 531-295-2550 E-Mail: Reiner.Suikat@dlr.de From andrewm@uow.edu.au Thu, 17 May 2001 23:15:20 +1000 Date: Thu, 17 May 2001 23:15:20 +1000 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] Slow connection in local domain "Suikat, Reiner" wrote: > > Hello, > > I'm experiencing a strange problem with Linux on my laptop. Any connection > within the local domain is extremely slow (< 5kB/sec), anything going > outside is normal (up to 200kB/sec). > > ... > May 17 09:27:13 beetlejuice kernel: eth0: using NWAY device table, not 8 hmm.. I hope I haven't goofed that transceiver selection. Here it's saying "your EEPROM says you have autoselect enabled, but you have NWAY. I'm using NWAY". It *should* work OK. Could you please run the diagnostics mentioned in the final section of Documentation/networking/vortex.txt? There's a copy at http://www.uow.edu.au/~andrewm/linux/vortex.txt Mainly, 'vortex-diag -aaee' and 'mii-diag -v' and the output with `debug=7'. Thanks. From Reiner.Suikat@dlr.de Thu, 17 May 2001 15:37:44 +0200 Date: Thu, 17 May 2001 15:37:44 +0200 From: Suikat, Reiner Reiner.Suikat@dlr.de Subject: AW: [vortex] Slow connection in local domain Andrew, thanks for your rapid reply!! Here is the output you asked for: insmod 3c59x debug=7 /etc/init.d/network start May 17 15:25:20 beetlejuice kernel: 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html May 17 15:25:20 beetlejuice kernel: See Documentation/networking/vortex.txt May 17 15:25:20 beetlejuice kernel: eth0: 3Com PCI 3c905C Tornado at 0xfb00, 00:00:39:71:33:24, IRQ 11 May 17 15:25:20 beetlejuice kernel: product code 0000 rev 00.11 date 00-00-00 May 17 15:25:20 beetlejuice kernel: Full duplex capable May 17 15:25:20 beetlejuice kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. May 17 15:25:20 beetlejuice kernel: MII transceiver found at address 24, status 782d. May 17 15:25:20 beetlejuice kernel: Enabling bus-master transmits and whole-frame receives. May 17 15:25:20 beetlejuice kernel: eth0: scatter/gather enabled. h/w checksums enabled Mai 17 15:25:27 beetlejuice sysctl: net.ipv4.ip_forward = 0 Mai 17 15:25:27 beetlejuice sysctl: net.ipv4.conf.all.rp_filter = 1 Mai 17 15:25:27 beetlejuice network: Setting network parameters: succeeded Mai 17 15:25:27 beetlejuice network: Bringing up interface lo: succeeded May 17 15:25:28 beetlejuice kernel: eth0: using NWAY device table, not 8 May 17 15:25:28 beetlejuice kernel: eth0: MII #24 status 782d, link partner capability 0021, info1 8010, setting full-duplex. Mai 17 15:25:28 beetlejuice network: Bringing up interface eth0: succeeded vortex-diag -aaee vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xfb00. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 7, registers values by window: Window 0: 0000 0000 0000 0000 fdfd 00bf ffff 0000. Window 1: FIFO FIFO 0700 0000 0000 003f 0000 2000. Window 2: 0000 7139 2433 0000 0000 0000 0002 4000. Window 3: 0000 0180 05ea 0020 000a 0800 0800 6000. Window 4: 0000 0000 0000 0cf6 0001 8880 0300 8000. Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000. Window 6: 0000 0000 0000 9f01 0100 58b3 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xfb00 0xFB10: **FIFO** 00000000 0000000a *STATUS* 0xFB20: 00000020 00000000 00080000 00000004 0xFB30: 00000000 c1ff3e01 063771c0 00080004 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:00:39:71:33:24. Configuration options 0002. EEPROM contents (64 words, offset 0): 0x000: 0000 3971 3324 9200 0000 0000 0000 0000 0x008: 2940 0000 0000 3971 3324 8010 0000 00aa 0x010: 72a2 0000 0000 0180 0000 0000 0429 1179 0x018: 0001 000a 0002 2900 ff6b 6b6b 0000 0000 0x020: 0000 ffff fff0 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 0x32aa. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:00:39:71:33:24 (used as a unique ID only). OEM Station address 00:00:39:71:33:24 (used as the ethernet address). Manufacture date (MM/DD/YYYY) 0/0/2000, division , product . Options: force full duplex, link beat required. Vortex format checksum is incorrect (0090 vs. 1179). Cyclone format checksum is incorrect (0xde vs. 00). Hurricane format checksum is incorrect (0x61 vs. 00). mii-diag -v mii-diag.c:v2.01a 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html MII PHY #24 transceiver registers: 3000 782d 0040 6174 05e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0001 0000 0000 0000 0000 0100 0000 003c d006 0f00 ff40 002c 0000 0080 000b The autonegotiated capability is 0000. No common media type was autonegotiated! This is extremely unusual and typically indicates a configuration error. Perhaps the advertised capability set was intentionally limited. Basic mode control register 0x6d64: Auto-negotiation disabled, with Speed fixed at 100 mbps, full-duplex. Transceiver isolated from the MII! Transceiver powered down! Transceiver in loopback mode! Basic mode status register 0x4001 ... 782d. Link status: previously broken, but now reestablished. This transceiver is capable of 100baseTx-FD. Unable to perform Auto-negotiation, negotiation not complete. Your link partner advertised 4001:. at least mii-diag is reporting a problem. Hope this helps! Thanks Reiner > -----Ursprüngliche Nachricht----- > Von: Andrew Morton [mailto:andrewm@uow.edu.au] > Gesendet: Donnerstag, 17. Mai 2001 15:15 > An: Suikat, Reiner > Cc: 'vortex@scyld.com' > Betreff: Re: [vortex] Slow connection in local domain > > > "Suikat, Reiner" wrote: > > > > Hello, > > > > I'm experiencing a strange problem with Linux on my laptop. > Any connection > > within the local domain is extremely slow (< 5kB/sec), > anything going > > outside is normal (up to 200kB/sec). > > > > ... > > May 17 09:27:13 beetlejuice kernel: eth0: using NWAY device > table, not 8 > > hmm.. I hope I haven't goofed that transceiver selection. Here > it's saying "your EEPROM says you have autoselect enabled, > but you have > NWAY. I'm using NWAY". It *should* work OK. > > Could you please run the diagnostics mentioned in the > final section of Documentation/networking/vortex.txt? > There's a copy at http://www.uow.edu.au/~andrewm/linux/vortex.txt > > Mainly, 'vortex-diag -aaee' and 'mii-diag -v' and the output > with `debug=7'. > > Thanks. > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex > From bogdan.costescu@iwr.uni-heidelberg.de Thu, 17 May 2001 16:07:33 +0200 (CEST) Date: Thu, 17 May 2001 16:07:33 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3com 900B not working with mandrake 8.0 (kernel 2.4.3) [ CC-ed back to vortex@scyld.com ] On Thu, 17 May 2001, Jacques Steennot wrote: > My problem is that I get vortex_suspend and vortex_resume in the syslog. > > It looks like this: > > May 17 15:01:18 mail kernel: vortex_suspend(eth0) > May 17 15:01:18 mail kernel: vortex_resume(eth0) Can you send the identification message given by the driver in /var/log/messages ? (all the 7-8 lines, not only the card name). These actions are normally associated with power-mode changes. Do you have any kind of power management system enabled (APM, ACPI) ? Can you try to disable it ? > This causes to crash the network connection to another mailserver and it > happens after 1 hour or so. Then I have to restart sendmail. I don't quite understand this. If the driver is resumed, it should operate again, with the same settings (f.e. IP) so, apart from some lost packets (if any), there shouldn't be any side effect. 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 andrewm@uow.edu.au Fri, 18 May 2001 00:23:11 +1000 Date: Fri, 18 May 2001 00:23:11 +1000 From: Andrew Morton andrewm@uow.edu.au Subject: AW: [vortex] Slow connection in local domain "Suikat, Reiner" wrote: > > mii-diag -v > > mii-diag.c:v2.01a 5/15/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > MII PHY #24 transceiver registers: > 3000 782d 0040 6174 05e1 0021 0000 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 1000 0001 0000 0000 0000 0000 0100 0000 > 003c d006 0f00 ff40 002c 0000 0080 000b The autonegotiated capability is > 0000. > No common media type was autonegotiated! > This is extremely unusual and typically indicates a configuration error. > Perhaps the advertised capability set was intentionally limited. > Basic mode control register 0x6d64: Auto-negotiation disabled, with > Speed fixed at 100 mbps, full-duplex. > Transceiver isolated from the MII! > Transceiver powered down! > Transceiver in loopback mode! > Basic mode status register 0x4001 ... 782d. > Link status: previously broken, but now reestablished. > This transceiver is capable of 100baseTx-FD. > Unable to perform Auto-negotiation, negotiation not complete. > Your link partner advertised 4001:. > > at least mii-diag is reporting a problem. > It certainly is. Most of those values are pretty much junk, I think. It's a 3c920 in a Toshiba Docking station. That's unusual, and something funny is going on. I'm afraid I don't have much to suggest. A workaround may be to use `options=4' or similar to bypass the MII. From bogdan.costescu@iwr.uni-heidelberg.de Thu, 17 May 2001 17:11:20 +0200 (CEST) Date: Thu, 17 May 2001 17:11:20 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] Slow connection in local domain On Thu, 17 May 2001, Suikat, Reiner wrote: > I'm experiencing a strange problem with Linux on my laptop. Any connection > within the local domain is extremely slow (< 5kB/sec), anything going > outside is normal (up to 200kB/sec). Please clarify this: is the slow speed related to your domain or to the device you're connecting to (hub/switch) ? > Empfangene Pakete:8427 Fehler:3 Weggeworfen:0 Überlauf:0 Rahmen:6 3 Rx errors, 6 Rx frame errors... 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 Thu, 17 May 2001 11:36:57 -0400 (EDT) Date: Thu, 17 May 2001 11:36:57 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: AW: [vortex] Slow connection in local domain I seem to have let out a bogus version of mii-diag! On Fri, 18 May 2001, Andrew Morton wrote: > "Suikat, Reiner" wrote: > > mii-diag -v > > mii-diag.c:v2.01a 5/15/2001 Donald Becker (becker@scyld.com) Note that this is a very new version. I didn't realize that I had copied this version to the FTP site -- it must have been picked up with some of the other updates. This version was intended only for internal testing. > > http://www.scyld.com/diag/index.html > > MII PHY #24 transceiver registers: > > 3000 782d 0040 6174 05e1 0021 0000 0000 This is normal -- you have sensed a 10baseT (implicitly half duplex) connection. > > The autonegotiated capability is 0000. Hmmm, obviously bogus. As are all of the following conclusions. > > No common media type was autonegotiated! > > This is extremely unusual and typically indicates a configuration error. > > Perhaps the advertised capability set was intentionally limited. > > Basic mode control register 0x6d64: Auto-negotiation disabled, with > > Speed fixed at 100 mbps, full-duplex. > > Transceiver isolated from the MII! > > Transceiver powered down! > > Transceiver in loopback mode! > > Basic mode status register 0x4001 ... 782d. > > Link status: previously broken, but now reestablished. > > This transceiver is capable of 100baseTx-FD. > > Unable to perform Auto-negotiation, negotiation not complete. > > Your link partner advertised 4001:. 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 coelho@persogo.com.br Thu, 17 May 2001 15:03:33 -0300 Date: Thu, 17 May 2001 15:03:33 -0300 From: =?iso-8859-1?Q?Leonardo_Rodrigues_Magalh=E3es?= coelho@persogo.com.br Subject: [vortex] Problems with auto-negotiation with 3c905 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0DEE2.8AE0B010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Guys, I got a running Linux Server ( Redhat 6.2 with kernel 2.2.19, 3c59x = driver version "3c59x.c 18Feb01" - the one that cames with kernel ) with = two 3c905B ( Cyclone ) cards. I'm having a problem that seems related to = auto-negotiating with my 3Com 10/100 hub. With no extra configuration ( i mean, enabling auto-negotiating on = both boards ), I got the following: eth0: Initial media type Autonegotiate. eth0: MII #24 status 786d, link partner capability 40a1, setting = half-duplex. eth1: Initial media type Autonegotiate. eth1: MII #24 status 786d, link partner capability 0020, setting = half-duplex. Eth0 is connected to 3Com hub, and eth1 is connected to a Cisco 805 = router ( cross over cable, no hub ). According to the page = http://www.scyld.com/diag/mii-status.html#lpar, I can conclude that eth1 = is negotiating 10BaseT and half-duplex with the Cisco Router. That's OK = and acceptable. Unfortunelly I couldn't understand what link partner = capability 40a1 from eth0 means. According to the same page, status = 0x4000 would mean 'Link partner got our advertised abilities'. = Unfortunely I can't understand what this means .... Would it mean 'We = sent autonegotiation information to the hub, but no responde received' = ????? Well, you should be asking ..... what's the problem anyway ?? The = problem is that letting eth0 get autonegotiation, it works poorly. I got = 35% of packet loss pinging a local machine, running on the same hub ( = network traffic is very low, no collision problems here ). All the = others machine on the network works very well, so I don't know if I = would be right on blaming the hub. Letting eth1 on autonegotiation, and = using 10BaseT negotiated with the Router, eth1 seems to work perfeclty = fine. Altough, eth0 just works when I use: options 3c59x options=3D0 on /etc/conf.modules, 'forcing' eth0 at 10BaseT. Question ...... can this be somehow a board problem ?? Can this be = somehow a hub problem ??? I need some advices ... Some more informations ...... ( cat /proc/pci ) Bus 0, device 10, function 0: Ethernet controller: 3Com 3C905B 100bTX (rev 48). Medium devsel. IRQ 12. Master Capable. Latency=3D32. Min = Gnt=3D10.Max Lat=3D10. I/O at 0x9000 [0x9001]. Non-prefetchable 32 bit memory at 0xde800000 [0xde800000]. Bus 0, device 11, function 0: Ethernet controller: 3Com 3C905B 100bTX (rev 48). Medium devsel. IRQ 10. Master Capable. Latency=3D32. Min = Gnt=3D10.Max Lat=3D10. I/O at 0x8800 [0x8801]. Non-prefetchable 32 bit memory at 0xde000000 [0xde000000]. Hope hearing from you soon, Leonardo Rodrigues Persocom Network ------=_NextPart_000_001B_01C0DEE2.8AE0B010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
    Hello = Guys,
 
    I got a running = Linux Server (=20 Redhat 6.2 with kernel 2.2.19, 3c59x driver version "3c59x.c 18Feb01" - = the one=20 that cames with kernel ) with two 3c905B ( Cyclone ) cards. I'm having a = problem=20 that seems related to auto-negotiating with my 3Com 10/100 = hub.
 
    With no = extra configuration=20 ( i mean, enabling auto-negotiating on both boards ), I got the=20 following:
 
eth0: Initial media type = Autonegotiate.
eth0:=20 MII #24 status 786d, link partner capability 40a1, setting=20 half-duplex.
eth1: Initial media type = Autonegotiate.
eth1:=20 MII #24 status 786d, link partner capability 0020, setting=20 half-duplex.
 
    Eth0 is = connected to 3Com=20 hub, and eth1 is connected to a Cisco 805 router ( cross over cable, no = hub ).=20 According to the page http://www.scyld.com/diag/mii-status.html#lpar, I=20 can conclude that eth1 is negotiating 10BaseT and half-duplex with the = Cisco=20 Router. That's OK and acceptable. Unfortunelly I couldn't understand = what link=20 partner capability 40a1 from eth0 means. According to the same page, = status=20 0x4000 would mean 'Link partner got our advertised abilities'. = Unfortunely I=20 can't understand what this means .... Would it mean 'We sent = autonegotiation=20 information to the hub, but no responde = received' ?????
 
    Well, you should be = asking .....=20 what's the problem anyway ?? The problem is that letting eth0 get=20 autonegotiation, it works poorly. I got 35% of packet loss pinging a = local=20 machine, running on the same hub ( network traffic is very low, no = collision=20 problems here ). All the others machine on the network works very = well, so=20 I don't know if I would be right on blaming the hub. Letting eth1 on autonegotiation, and using 10BaseT negotiated = with the=20 Router, eth1 seems to work perfeclty fine.
 
    Altough, eth0 just = works when I=20 use:
 
options 3c59x options=3D0
 
    on = /etc/conf.modules, 'forcing'=20 eth0 at 10BaseT.
 
    Question ...... can = this be=20 somehow a board problem ?? Can this be somehow a hub problem ??? I need = some=20 advices ...
 
 
    Some more = informations ...... (=20 cat /proc/pci )
 
  Bus  0, device  10, = function =20 0:
    Ethernet controller: 3Com 3C905B 100bTX (rev=20 48).
      Medium devsel.  IRQ = 12.  Master=20 Capable.  Latency=3D32.  Min Gnt=3D10.Max=20 Lat=3D10.
      I/O at 0x9000=20 [0x9001].
      Non-prefetchable 32 bit = memory at=20 0xde800000 [0xde800000].

  Bus  0, device  = 11,=20 function  0:
    Ethernet controller: 3Com 3C905B = 100bTX=20 (rev 48).
      Medium devsel.  IRQ = 10. =20 Master Capable.  Latency=3D32.  Min Gnt=3D10.Max=20 Lat=3D10.
      I/O at 0x8800=20 [0x8801].
      Non-prefetchable 32 bit = memory at=20 0xde000000 [0xde000000].
 

    Hope hearing = from you=20 soon,
    Leonardo Rodrigues
    = Persocom=20 Network
------=_NextPart_000_001B_01C0DEE2.8AE0B010-- From kluro@yahoo.com Fri, 18 May 2001 01:49:19 -0700 (PDT) Date: Fri, 18 May 2001 01:49:19 -0700 (PDT) From: nn nn kluro@yahoo.com Subject: [vortex] RX errors, kernel 2.4.4, 3Com 905B MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I am having some trouble getting my 3c905B (BNC) card to work properly under kernel 2.4.4 (SMP). As it worked fine with 2.2.14, I assume this is a driver problem. The network is working, but very slow, and I get the following from ifconfig: eth0 Link encap:Ethernet HWaddr 00:10:5A:DB:D0:39 inet addr:130.235.91.187 Bcast:130.235.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:72131 errors:126 dropped:0 overruns:0 frame:228 TX packets:1245 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:16 Base address:0xec00 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1130 errors:0 dropped:0 overruns:0 frame:0 TX packets:1130 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 I am using the 3c59x driver as a module, with options in modules.conf as: alias eth0 3c59x options eth0 options=0x203 debug=3 Without options, I get "No route to host". >From /var/log/messages: May 18 09:39:03 naglfar kernel: 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/ne twork/vortex.html May 18 09:39:03 naglfar kernel: See Documentation/networking/vortex.txt May 18 09:39:03 naglfar kernel: eth0: 3Com PCI 3c900 Cyclone 10Mbps TPC at 0xec00, 00:10:5a:db:d0:39, IRQ 16 May 18 09:39:03 naglfar kernel: product code 5051 rev 00.4 date 12-07-98 May 18 09:39:03 naglfar kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. May 18 09:39:03 naglfar kernel: Media override to transceiver type 3 (10base2). May 18 09:39:03 naglfar kernel: Enabling bus-master transmits and whole-frame receives. May 18 09:39:03 naglfar kernel: eth0: scatter/gather enabled. h/w checksums enabled May 18 09:39:03 naglfar kernel: eth1: 3Com PCI 3c905B Cyclone 100baseTx at 0xe880, 00:c0:4f:68:47:79, IRQ 19 May 18 09:39:03 naglfar kernel: product code 4920 rev 00.0 date 07-03-97 May 18 09:39:03 naglfar kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. May 18 09:39:03 naglfar kernel: MII transceiver found at address 24, status 7809. May 18 09:39:03 naglfar kernel: Enabling bus-master transmits and whole-frame receives. May 18 09:39:03 naglfar kernel: eth1: scatter/gather enabled. h/w checksums enabled May 18 09:39:06 naglfar kernel: eth0: Media override to transceiver 3 (10base2). May 18 09:39:11 naglfar modprobe: modprobe: Can't locate module char-major-5 lspci yields: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:0d.0 Ethernet controller: 3Com Corporation 3c900B-TPC [Etherlink XL TPC] (rev 04) 00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] 00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 01:00.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) I do not know much about this stuff, so any help is welcome. Best regards, Mikael Borg __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From andrewm@uow.edu.au Fri, 18 May 2001 21:23:06 +1000 Date: Fri, 18 May 2001 21:23:06 +1000 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] RX errors, kernel 2.4.4, 3Com 905B nn nn wrote: > > options eth0 options=0x203 debug=3 What happens if you use options eth0 options=3 ? From bogdan.costescu@iwr.uni-heidelberg.de Fri, 18 May 2001 14:49:51 +0200 (CEST) Date: Fri, 18 May 2001 14:49:51 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] Problems with auto-negotiation with 3c905 On Thu, 17 May 2001, Leonardo Rodrigues Magalhães wrote: > Well, you should be asking ..... what's the problem anyway ?? The > problem is that letting eth0 get autonegotiation, it works poorly. I got > 35% of packet loss pinging a local machine, running on the same hub ( > network traffic is very low, no collision problems here ). Can you get and run mii-diag from ftp.scyld.com and post the results for eth0 ? Also is it possible that you have a bad cable on eth0 (which might work at 10, but not at 100Mbit/s) ? 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 kluro@yahoo.com Fri, 18 May 2001 07:09:41 -0700 (PDT) Date: Fri, 18 May 2001 07:09:41 -0700 (PDT) From: nn nn kluro@yahoo.com Subject: [vortex] RX errors, kernel 2.4.4, 3Com 905B Fixed it !! Thank you very much! /Mikael Borg --- Andrew Morton wrote: > nn nn wrote: > > > > options eth0 options=0x203 debug=3 > > What happens if you use > > options eth0 options=3 > > ? __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From madmatt@bits.bris.ac.uk Fri, 18 May 2001 16:37:29 +0100 (BST) Date: Fri, 18 May 2001 16:37:29 +0100 (BST) From: Matt madmatt@bits.bris.ac.uk Subject: [vortex] 3c980tx problems Matt mentioned the following: | I've compiled both mii-diag and vortex-diag, and these seem to work and | report the autonegotiation. I can post the output of these if it's any | help. | | The card seems to work fine apart from it just drops packets :( Hmm, fixed the problem. Guess what? The PSU in the machine was failing. The machine is reasonably loaded with a gfx card, soundcard, cdrom, hard disk, floppy, lcd display, pair of cpu fans, etc. If I forced the card to work in 10base, it wouldn't drop packets, but as soon it went back to 100base, 5%-ish of packets would go missing. After power-cycling the box a few times, it wouldn't even negotiate to the switch. If I touched both the switch and the case, it would just about manage it, until I released them again. :) Meanwhile, no other device showed any symptoms of lack of power. Replacing the PSU with a 350W unit has solved the problem. I dunno about AMD-approved PSU's, more like 3Com-approved units. What are these cards up to eh? THanks anyway Matt From martijn.ras@cable4u.nl Fri, 18 May 2001 17:20:24 -0400 Date: Fri, 18 May 2001 17:20:24 -0400 From: Martijn Ras martijn.ras@cable4u.nl Subject: [vortex] Twofold problem with setting up 3Com PCI 3c900 Cyclone 10Mbps TPO in RedHat 6.1 system, updated to kernel 2.4.X. Heya Folks, My RedHat 6.1 system originally used kernel 2.2.12-20, at first i updated to kernel 2.2.16. In both kernel's i've not experienced any problems. As i want to use my USB printer i thought i'd just update to the 2.4 kernel ... so i downloaded kernel 2.4.2 and after some hazzle i got my printer going. I'm completely cut off the internet though ... :( ... First there's a complaint about "ip_always_defrag" not being there, seen some messages on that one on the net but haven't figured out how to get around it though. Anyways, i can see my cable modem indicating there's something being send, just as with the kernel 2.2.X. That's the end of the line though, there's a wait and no bell is rung to indicate a DHCP offer returning. The kernel just continues after a while and leaves me stand-alone. Here's the dmesg output, first the parts which are of interest, the whole lot is included below: ... First we the ip_always_defrag ... we'll see about the IP stuff ... first get the ethernet card going else IP doesn't make itself too usefull ... ... Goodies, looks like we found our ethernet card, so far so good ... :) ... ... PCI: Found IRQ 10 for device 00:0b.0 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt eth0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xa400, 00:50:da:e2:f3:c6, IRQ 10 product code 5751 rev 00.4 date 01-22-00 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 182d. Enabling bus-master transmits and whole-frame receives. ... Yup, that sums it up pretty much ... ... eth0: scatter/gather enabled. h/w checksums enabled ... Guess we need things enabled to get hooked up, go on ... :) ... ... almost done ... :( ... ... eth0: using NWAY device table, not 8 eth0: using NWAY device table, not 8 ... Not? ... Mazzel, Martijn. Linux version 2.4.4 (root@PiAlpha) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu May 17 19:54:41 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000ffec000 (usable) BIOS-e820: 000000000ffec000 - 000000000ffef000 (ACPI data) BIOS-e820: 000000000ffef000 - 000000000ffff000 (reserved) BIOS-e820: 000000000ffff000 - 0000000010000000 (ACPI NVS) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux-2.4.4 ro root=307 Initializing CPU#0 Detected 700.038 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1395.91 BogoMIPS Memory: 255340k/262064k available (1120k kernel code, 6336k reserved, 418k data, 208k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c3f9ff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c3f9ff 00000000 00000000 CPU: After generic, caps: 0183f9ff c1c3f9ff 00000000 00000000 CPU: Common caps: 0183f9ff c1c3f9ff 00000000 00000000 CPU: AMD Athlon(tm) Processor stepping 01 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf1010, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Disabled enhanced CPU to PCI posting PCI: Disabled enhanced CPU to PCI posting #2 Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 169669kB/56556kB, 512 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA hda: IBM-DPTA-372050, ATA DISK drive hdb: SAMSUNG SV1533D, ATA DISK drive hdc: IDE/ATAPI CD-ROM 50XS, ATAPI CD/DVD-ROM drive hdd: ARW4424P, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=2495/255/63 hdb: 29897280 sectors (15307 MB) w/472KiB Cache, CHS=1861/255/63 hdc: ATAPI 11X CD-ROM drive, 128kB Cache, UDMA(16) Uniform CD-ROM driver Revision: 3.12 hdd: ATAPI 24X CD-ROM CD-R/RW drive, 2048kB Cache, DMA Partition check: hda: hda1 hda2 < hda5 hda6 hda7 > hdb: hdb1 hdb2 hdb3 Floppy drive(s): fd0 is 1.44M, fd1 is 1.44M FDC 0 is a post-1991 82077 NTFS version 010116 Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A PCI: Found IRQ 10 for device 00:0b.0 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt eth0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xa400, 00:50:da:e2:f3:c6, IRQ 10 product code 5751 rev 00.4 date 01-22-00 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 182d. Enabling bus-master transmits and whole-frame receives. eth0: scatter/gather enabled. h/w checksums enabled Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 203M agpgart: unsupported bridge agpgart: no supported devices found. SCSI subsystem driver Revision: 1.00 scsi0 : SCSI host adapter emulation for IDE ATAPI devices usb.c: registered new driver usbdevfs usb.c: registered new driver hub PCI: Found IRQ 5 for device 00:04.2 PCI: The same IRQ used for device 00:04.3 uhci.c: USB UHCI at I/O 0xd400, IRQ 5 uhci.c: detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb.c: kmalloc IF cff06d80, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB UHCI-alt Root Hub SerialNumber: d400 hub.c: USB hub found hub.c: 2 ports detected hub.c: standalone hub hub.c: ganged power switching hub.c: global over-current protection hub.c: power on to power good time: 2ms hub.c: hub controller current requirement: 0mA hub.c: port removable status: RR hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface cff06d80 PCI: Found IRQ 5 for device 00:04.3 PCI: The same IRQ used for device 00:04.2 uhci.c: USB UHCI at I/O 0xd000, IRQ 5 uhci.c: detected 2 ports usb.c: new USB bus registered, assigned bus number 2 usb.c: kmalloc IF cff06f40, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB UHCI-alt Root Hub SerialNumber: d000 hub.c: USB hub found hub.c: 2 ports detected hub.c: standalone hub hub.c: ganged power switching hub.c: global over-current protection hub.c: power on to power good time: 2ms hub.c: hub controller current requirement: 0mA hub.c: port removable status: RR hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface cff06f40 usb.c: registered new driver usblp NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 208k freed uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6 uhci.c: suspend_hc hub.c: port 1 connection change hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s hub.c: port 2 connection change hub.c: port 2, portstatus 300, change 3, 1.5 Mb/s uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6 uhci.c: suspend_hc hub.c: port 1 connection change hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s hub.c: port 2 connection change hub.c: port 2, portstatus 300, change 3, 1.5 Mb/s uhci.c: root-hub INT complete: port1: 588 port2: 588 data: 6 hub.c: port 1 enable change, status 300 hub.c: port 2 enable change, status 300 uhci.c: root-hub INT complete: port1: 588 port2: 588 data: 6 hub.c: port 1 enable change, status 300 hub.c: port 2 enable change, status 300 Adding Swap: 265032k swap-space (priority -1) cdrom: open failed. VFS: Disk change detected on device ide1(22,0) cdrom: open failed. VFS: Disk change detected on device ide1(22,64) eth0: using NWAY device table, not 8 eth0: using NWAY device table, not 8 cdrom: open failed. VFS: Disk change detected on device ide1(22,0) cdrom: open failed. VFS: Disk change detected on device ide1(22,64) From andrewm@uow.edu.au Sat, 19 May 2001 14:29:25 +1000 Date: Sat, 19 May 2001 14:29:25 +1000 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] Twofold problem with setting up 3Com PCI 3c900 Cyclone 10Mbps TPO in RedHat 6.1 system, updated to kernel 2.4.X. Martijn Ras wrote: > > Heya Folks, > > My RedHat 6.1 system originally used kernel 2.2.12-20, at first i > updated to kernel 2.2.16. In both kernel's i've not experienced any > problems. It *looks* OK. It'll just autonegotiate. There seems to be an occasional problem with kernel 2.4 and some DHCP clients. Haven't been able to pin it down, but it seems that the netdevice startup timing has changed and this breaks older versions of, at least, pump. We need to eliminate a variable. Is it the NIC driver, or is it the DHCP timing problem? Are you able to test the interface without having a dependency on DHCP? Can you please send the vortex-diag and mii-diag output, as per the final section of Documentation/networking/vortex.txt? Can you try the following: - ifconfig eth0 up - wait five seconds - `pump eth0' (or dhcpcd). Some `tcpdump' traces on eth0 while this is happening would be useful. Also, does `ifconfig' indicate that frames have been received? From hamid@morva.net Fri, 25 May 2001 22:59:35 +0330 Date: Fri, 25 May 2001 22:59:35 +0330 From: Hamid Hashemi Golpayegani hamid@morva.net Subject: [vortex] 3c59x 3c905C problems Hi, I have a problem with a 3com 905C card . I am using kernel 2.4.4 and the card was installed successfully and linux work with this card cool . I am running squid on this linux box as a webcache and all things works good for a while . after about 1 hour the ping time of this machine that works 100Mb/Fullduplex increase to about 1000ms that cause the slow working for my users . I am using a 1 Mb/Sec line and this squid box . I have use DecDigital chip before and with halfduplex mode and I don't have this problem . would you please help me ?! -- Regards ================================================================= / Seyyed Hamid Reza / WINDOWS FOR NOW !! / / Hashemi Golpayegani / Linux for future , FreeBSD for ever / / Morva System Co. / ------------------------------------- / / Network Administrator/ hamid@morva.net , ICQ# : 42209876 / ================================================================ From bogdan.costescu@iwr.uni-heidelberg.de Mon, 28 May 2001 13:34:24 +0200 (CEST) Date: Mon, 28 May 2001 13:34:24 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c59x 3c905C problems On Fri, 25 May 2001, Hamid Hashemi Golpayegani wrote: > after about 1 hour the ping time of this machine that works > 100Mb/Fullduplex increase to about 1000ms that cause the slow working for my > users . I am using a 1 Mb/Sec line and this squid box . It's not clear to me how your network is arranged. Is it like this: computers --- hub/switch ----------- squid computer ----- ouside ^ ^ 100Mb-FD 1Mb > I have use DecDigital chip before and with halfduplex mode and I don't > have this problem . So you think that the problem is with the full-duplex setting of the 3C905C ? I can't imagine a way for the card to work fine for an hour, than to fail in this way. If you think that the duplex setting is your problem, you could try running mii-diag (from ftp://ftp.scyld.com/diag) and post your results here. When this problem appears and you ping: from which computer to which computer are you sending packets ? What kind of 1Mb connection do you have ? Is this through a second NIC connected to a modem (a la DSL) or something else ? 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