Problems with 3Com 3C920 Integrated NIC & GX150s

It sounds like you are more interested in venting than getting help, but a few more details in the message might help.  What version driver is on the GX150, What kind of switches are you connecting to?  Does the RJ-45 connector provide a positive lock?  What OS is running on the GX150s?

Droid

Oh man - and I thought I was alone on this one.

I had a GX150 go nuts on me two months ago (wouldn't turn on at all). Dell sent someone over to change RAM and Motherboard - but that's just when my trouble started.

 

The 150 is used as a development server for me alone, so it's network load is not high - and hence my problems were hardly noticeable in the beginning.

 

But to make a long, tiresome story short: I have the exact same problems that you describe (although in a much smaller environment) This problem occurs on all Windows OSs from NT4 and forward (haven't tried Linux, but including servers and beta-releases), with all assortments of drivers, IP-configs, you name it.

 

Dell insists that this is a software error, since the diagnostics turn up nothing, yet I believe that it is a hardware error - I even had a MCSE-certified engineer go over it. With certain tweaks and probably forcing 10 Mb, etc. he got it to work on a Windows 2000 Advanced Server, but it's not stable in my environment.

 

The only thing I haven't tried yet is getting a crossed patch cable and connecting it directly to one of the other machines. Apparently, they say, 3Com NICs are known to have problems with certain types of switches - so if you have another type of switch, try plugging one of the lousy machines into that one instead.

 

Regards,

 

Anders

This problem sounds more like "we changed out hubs for switches" problem. I have over 5000 GX150's running on a very Diverse network that includes, Appletalk, Banyan Vines, Netware 3,4,5,6
NT 4.0, WIN2000, and workstations running 95,98,2000,Me and XP.


When one group installed Cisco 2950 switches in place of 10 Meg hubs this became a problem.

Enableing Spanning Tree Port Fast on specific ports and making sure that the net was setup in a STAR fashion instead of hubs daisy chained like a choo choo train fixed the problem.

With Hubs you are all on the same segment. With switches you
have to do more than just plug them in and get the Link status lights to show up.

The 3C920 (3C905B compatable 10/100 nic) is unlikely to be the real problem.

That's not quite it.

I do have a switch (one) on the network - but that's the way it has always been.

The only thing that has changed from when my system was working fine to not working is that the GX150 blew a fuse or something, Dell came and changed RAM, motherboard, etc.

Before this everything worked perfectly. After this the other machines in the network still work perfectly - but the GX150 will do absolutely nothing when it concerns network issues.

/Anders

NT4 REQUIRES pnpisa.inf before the nic will work.

LMHOSTS and WINS affect this also.

I don't really care what NT needs. I have the problem on 98, Me, Nt, 2000, XP, .NET Server 2003 (both RC's). With or without the newest drivers supplied by Dell or MS - it doesn't make a difference.

/Anders

The number of switches doesnt matter. Spanning Tree Port fast DOES matter.

Again. If you use a Hub or turn on spanning tree port fast the problem is solved.

 

Others talk about

ip helper-address XXX.XXX.XXX.XXX

the switch may not be passing the WINS requests along.
Put that line in with the IP address for the WINS server 
Also see:

http://www.itp-journals.com/nasample/p1417.pdf

There is no problem whatsoever with the 3COM integrated NIC.

Spanning Tree portfast cannot be done where hubs are daisychained off from the switches. So this is not done on all the ports. Also HANGING a 10Meg Hub off of
a port set this way will KILL the entire LAN. So planning is a must when doing this type of config.

Also I am sure that daisy chaining the switches like a train is not the best way to
set them up. It must be that a star configuration where the switches are all tied to
a central switch.

Cisco 2950 looks something like this in the IOS

#SH config
Using 3585 out of 32768 bytes
!
! Last configuration change at 22:03:55 UTC Wed Aug 8 2001 by admin
! NVRAM config last updated at 22:04:05 UTC Wed Aug 8 2001 by admin
!
version 12.0
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname 2950

!
ip subnet-zero
!
!
!
interface FastEthernet0/1
!
interface FastEthernet0/2
spanning-tree portfast
!
interface FastEthernet0/3
spanning-tree portfast
!
interface FastEthernet0/4
spanning-tree portfast
!
interface FastEthernet0/5
spanning-tree portfast
!
interface FastEthernet0/6
spanning-tree portfast
!
interface FastEthernet0/7
spanning-tree portfast
!
interface FastEthernet0/8
spanning-tree portfast
!
interface FastEthernet0/9
spanning-tree portfast
!
interface FastEthernet0/10
spanning-tree portfast
!
interface FastEthernet0/11
spanning-tree portfast
!
interface FastEthernet0/12
spanning-tree portfast
!
interface FastEthernet0/13
spanning-tree portfast
!
interface FastEthernet0/14
spanning-tree portfast
!
interface FastEthernet0/15
spanning-tree portfast
!
interface FastEthernet0/16
spanning-tree portfast
!
interface FastEthernet0/17
spanning-tree portfast
!
interface FastEthernet0/18
spanning-tree portfast
!
interface FastEthernet0/19
spanning-tree portfast
!
interface FastEthernet0/20
spanning-tree portfast
!
interface FastEthernet0/21
spanning-tree portfast
!
interface FastEthernet0/22
spanning-tree portfast
!
interface FastEthernet0/23
spanning-tree portfast
!
interface FastEthernet0/24
spanning-tree portfast
!
interface FastEthernet0/25
!
interface FastEthernet0/26
!

 

So. Now I've attached a 10/100 hub instead. No fancy stuff there. Same deal.

Three machines active on the LAN - two still works fine together and on the net, and then there's the GX150. For that one it is still the same deal.

It seems like it recieves data-packages OK, and hence it must return ACK-packages OK as well. Also, as noted above, certain simple tasks will work on the internet - but as soon as it has to send real data, it messes up.

It can browse foldes on a healthy machine - but if it tries to update some of the 'auto' files in XP (like thumbnails.db) it fails.

 

/Anders

There is no such thing as a 10/100 Hub. If its 10/100 its a switch.


If its 100Meg Only its a Hub or if its 10 meg Only its a Hub.


Poor wiring and or Non twisted pair wiring will work on 10 meg ethernet but will mess up on 100 meg.

If you use a 10 Meg Only Hub the results will be much different.

Yeah, that's what I thought, too... But I looked it up - as I wanted to be precise in my argument - and the vendor consistently referred to this particular model as a hub.

As for cable quality, I use only professional cables.

Anyway, it doesn't really matter - it has been tested at a site with tons of different equipment, all to no avail.

 

/Anders

You havent given a netlist of whats attached to what. Are there switches and routers inbetween? Have you tried the Choo Choo method or is it a Star Configuration. Using cross overs is NOT a good Idea. You should have a Central Hub or Switch and at Max 1 Switch or Hub off of that. Not Switch Daisychain Hub Daisychain Switch etc.

If you take a 10 Meg half Duplex Hub and hook the Server and the Workstation into it does it work? There is also the 2 Repeater rule for hubs. You cannot tie hubs in series and see anything past 2 hops. Aka Hub Hub works but Not Hub Hub Hub and so on. With 3 hops the ones in the middle can see the outside but the ones on the end cannot see each other and can see the middle just fine.

http://www.lpt.com/windowsnetworking/regusers/netrule.htm

The 5-4-3 Collision Rule

Collisions are an inherent part of Ethernet. Since a sending station may transmit at any time, its transmission may collide with transmissions from other stations. When a collision is detected, the sending station backs off, waits awhile and attempts to retransmit. This retransmission process is very efficient when performed by hardware. In a large network, if the data travel delay time between two stations is too long, a collision may occur without the sending station's hardware detecting it. Typically, a software function detects the loss of the sent data and initiates a retransmission process. This retransmission process is very inefficient when performed by software.

The 5-4-3 collision rule was defined by the IEEE 802.3 standard as a set of criteria that when followed, will ensure the detection of collisions by hardware. The following paragraphs summarize the main criteria points.

The main criterion dictates that two stations (DTEs) should not be separated by more than 5 segments and 4 repeaters. In the maximum configuration the following restrictions apply: (a) No more than 3 of the segments should be of a shared type (e.g. coax). (b) No fiber segments should exceed 500 m.

When two stations are separated by 4 segments and 3 repeaters the following restrictions apply: (a) Inter-repeater fiber segments should not exceed 1000 m. (b) Station to repeater segments should not exceed 400 m. There are no restrictions on using shared segments.

The 5-4-3 rule is an approximation. In large networks, or when specific distances are required, the reader is encouraged to use the IEEE 802.3 detailed calculation guidelines

In this case two hubs are connected via uplink cables to a third hub. Six workstations are connected via fiber to the hubs. The worse collision path is between two stations connected to each of the lower hubs. In this case there are 4 segments, 3 repeaters and 0 shared segments (4-3-0). Therefore, limiting the fiber runs to 400 m satisfies the requirements of the collision rule.

 

 

Ok,  I have the same problem and have seen several emails and posts on the net outlining this problem.  I know that you have a lot of machines running properly but  I have two identical optiplex running side by side, one has the slows problems one doesn't.    I am an experienced networker and have tried the cabling, extra. If I switch the connectivity from the one running correctly to the slow one the problem persists.  It seems very likely that  is there is something wrong with certain Dell intergrated nics.  It is not every one but about half of the ones I have.  I would love a response from Dell on this.

The setup is almost as simple as can be:

 

One switch/hub with four cables connected: one cable to the sick Optiplex (GX150), one cable to a working Optiplex (GX240), one cable to a no-name machine with (I think) an Accton NIC. And one cable to my HW Firewall that is again connected to the router, connecting me to the 'net.

 

Everything worked like a charm - network-wise - until Dell replaced the motherboard on my GX150. Now everything but the GX150 works fine with regards to networking.

 

/Anders

Ok here is what I found.  I went through every segement and found that one of the switches in the middle of the chain was using half duplex for a fiber link.  Changing this to full duplex and setting the nic's to 100tx with the rest of the settings at the defaults works. 

 

What this tells me is that these cards are defective.  I have many other nics running over thet same connections using auto-sensing that work fine.  Also windows 98 machines with the same hardware work fine.  Finding this work around has solved the short term problem butl having to set many nics is not a good long term fix. 

If you call dell tech support they send you a new motherbaord which may or may not help.  I would love to see Dell come forward and address this issue.  There are a growing number of posts about this behavior so it is not an isolated incident.

 

Tom Slattery

The vast majority of problems with networking are related to one of the following issues:

• LAN-specific settings, including IP and NetBIOS configurations
  
  
• Switches with spanning tree, which need to either have spanning tree disabled or PortFast enabled on ports connected to affected systems
  
  
• Incompatibilities with auto-sensing between certain networking hardware and integrated or PCI-based network cards (rare)
  
  
• A defective network card within the system itself

The network cards installed within Dell systems have been tested and validated by Dell for use with the majority of network solutions. Dell cannot possibly test every switch, hub, and router combination.

If you believe that your network card is defective, you may need to contact Dell technical support and, after performing any necessary diagnostics, request a replacement network card or motherboard, if within warranty.