From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
I am using 4 LP2000R (HP Netservers) loaded with Redhat Linux 7.1
(Kernel2.4.2-2)
Each LP2000R has dual 933MHZ and 512MB of RAM.  Additionally they
each carry an Emulex LP8000 fiber channel adapter card with v4.10l or 
later of the emulex driver.

The four clients above a connected to a brocade fiber channel switch
(SilkWorm 2800) which is connected to an XP48.  The switch is set to 
a fabric point-to-point mode and connected to an XP512 on a single port.

The I/O stress test we ran pretty much create ext2 file system on a
device on the array after mounting it, then reads/writes from it and later 
unmounts it.  This operation is performed over and over again for X number 
of hours.

Problem - Kernel 2.4.2-2 Redhat 7.1
 - The configuration described above runs for about 20-25hours before one 
of the clients stops I/O traffic because it is hung on a mount or umount.  
This problem exists in Redhat Linux 7.1 (Kernel 2.4.2-2).  This can always 
be duplicated.
I tried the raw 2.4.2 kernel from kernel.org.
That kernel does not appear to have the problem either. 
I also tried using Redhat's latest release 2.4.3 source rpm and the 
problem seemed to have been fixed in that kernel. However, other major 
things were not working for us in that kernel which kept us from making 
the transition.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Set up configuration as describe in description box.
2.Simulate heavy Fibre Channel I/O stress on all four clients
3.
	

Actual Results:  Let the configuration ran for a while and eventually a 
client or more hang and stop I/O traffic.  Often the client completely 
hangs and sometimes it responds to keyboard inputs even though it is hang.

Expected Results:  This configuration should be able to run 96+ continous 
hours without interruption.  No server hang, data corruption, errors etc.

Additional info:

I selected the mount package to report this bug because it it was the 
closest match to our issue.  This bug doesn't really have to do with the 
mount package itself.  It's more the way the kernel handle locking of 
resources during such operations.  What we beleive is happening is a 
problem with some type of malprocessing of a spinlock in the 
file /fs/super.c that causes the umount operation to hang.  Since 
mount/umount are sequential this also hangs all subsequent umount and 
mounts.