Bug 15075

Summary:	Intel Etherexpress Pro timeouts when >1 card present
Product:	Base System	Reporter:	lyndon <lyndon>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description lyndon 1999-11-24 17:20:00 UTC

intel Etherexpress Pro 10/100B Ethernet (one on intel n440bx2 board, other as PCI expansion).
platform is a VAResearch VAR-501, dual pIII stepping 2 500mHz, 512mb RAM.
When only one card is ifconfig'd up and link up, everything is great.  try and
bring up the other card, and within 36 hours both interfaces stop responding.
error on console:
server /kernel: fxp1: device timeout
server /kernel: fxp0: device timeout
repeatedly until reboot.
the only kernel changes are as follows:
	maxusers 120 (changed from 32)
	options SMP (uncommented to build SMP)
	options APIC_IO (uncommented to build SMP)
	options NBUS=2 (uncommented to build SMP)
The problem results in a server that doesn't talk on any network, but is
available via local console or tty

How-To-Repeat: link up and ifconfig up both interfaces.  This happens (to me, anyways) regardless
of which interface is on what network.  There is no problem if only one of the interfaces
is config'd and up, regardless of which interface.  I have reproduced this
on three identically-configured machines.

Comment 1 Chris Dillon 1999-11-24 20:45:11 UTC

On Wed, 24 Nov 1999 lyndon@bsd4us.org wrote:

> intel Etherexpress Pro 10/100B Ethernet (one on intel n440bx2
> board, other as PCI expansion). platform is a VAResearch VAR-501,
> dual pIII stepping 2 500mHz, 512mb RAM. When only one card is
> ifconfig'd up and link up, everything is great.  try and bring up
> the other card, and within 36 hours both interfaces stop
> responding. error on console:

Interesting.  I currently have a large Compaq server with 6 Intel
EtherExpress Pro 10/100 and 1 Dual Intel EtherExpress Pro 10/100 --
for a total of 8 interfaces -- running 3.3-STABLE (and initally was
running 3.3-RELEASE, as you are) with no problems at all.  See my
paragraph below, however.

> server /kernel: fxp1: device timeout
> server /kernel: fxp0: device timeout
> repeatedly until reboot.
> the only kernel changes are as follows:
> 	maxusers 120 (changed from 32)
> 	options SMP (uncommented to build SMP)
> 	options APIC_IO (uncommented to build SMP)
> 	options NBUS=2 (uncommented to build SMP)

I do recall having some kind of interrupt-related problem which caused
many of the interfaces to stop working when I temporarily added a
second processor to the machine to play with SMP.  Try using a non-SMP
kernel and see if that fixes the problem.  You may even have to remove
the additional processor(s) entirely to fix the problem.  If there
indeed is a problem related to SMP here, I'm sure some of the
developers would love to know about it.  Don't ask me though, that
certainly isn't my area of expertise.  :-)

-- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net
   FreeBSD: The fastest and most stable server OS on the planet.
   For Intel x86 and Alpha architectures (SPARC under development).
   ( http://www.freebsd.org )

   "One should admire Windows users.  It takes a great deal of
    courage to trust Windows with your data."

Comment 2 ajk 2000-07-03 16:26:15 UTC

I'm experiencing this problem with 4.0-STABLE.  I have four Dell
PowerEdge 2450s, each with one interface on the main board and a
dual-port card.  Only one interface can be used at a time.

Can the priority be increased on this PR?  This configuration is
probably a common one.

-- 
Andrew J. Korty, Principal Security Engineer
Office of the Vice President for Information Technology
Indiana University

Comment 3 Mike Barcroft freebsd_committer

2001-07-21 19:15:37 UTC

State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?

Comment 4 Mike Barcroft freebsd_committer

2001-07-24 01:04:41 UTC

State Changed
From-To: feedback->closed


Originator is unable to test with a newer versions of FreeBSD.  There 
have been a lot of changes to the fxp driver since this PR was created, 
so it's probable this problem has been solved.  If this is still a 
problem with a newer version of FreeBSD, a new PR should be opened.