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
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
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
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Set up configuration as describe in description box.
2.Simulate heavy Fibre Channel I/O stress on all four clients
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.
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
Created attachment 29974 [details]
trace file from sysrq keys
If it's dependent on the kernel version, it's not a problem with the mount
I would be very interested why the 2.4.3-12 kernel is not working well for you.
no reply made