Bug 68673

Summary: Kernel hangs when using loopback device
Product: [Retired] Red Hat Linux Reporter: Need Real Name <itooon>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 7.3CC: barryn, craig.lawson
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:39:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2002-07-12 13:26:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
I'm using kernel (2.4.18-5smp).
When I have applied heavy load to loopback device, a kernel will hang-up.

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


How reproducible:
Always

Steps to Reproduce:
1. dd if=/dev/zero of=test.img bs=1024k count=1024 
2. losetup /dev/loop1 test.img
3. mke2fs -j /dev/loop1
4. mkdir /mnt/test
5. mount /dev/loop1 /mnt/test
6. cd /mnt/test
7. iozone -a 

(iozone can download from http://www.iozone.org )

Actual Results:  The reaction of a console is lost.
Ctrl + alt + delete key reset is also ineffective.
kernel hang up.

Expected Results:  It is that a benchmark tool (iozone) is completed with no 
problems.


Additional info:

In the case of 2.4.18-4smp, it becomes as expected.

Comment 1 Arjan van de Ven 2002-07-12 13:30:18 UTC
Ok we didn't actually change loop between -4 and -5

however is sysreq-t possible ?
(and if keyboard REALLY doesn't respond, please try adding nmi_watchdog=1 to the
vmlinuz line in /boot/grub/grub.conf)

Comment 2 Craig Lawson 2003-11-06 08:25:00 UTC
(One year later...)

This old, unresolved bug describes my problem exactly. I am using Red 
Hat 9 with 2.4.20-20.9smp. I also tried it with 2.4.20-19.9 in single 
processor mode. I set nmi_watchdog=1. The system always hangs, 100% 
repeatable.

As the original poster did, I created a script to isolate the problem.
When I run the fatal script under Gnome, the system simply freezes and 
does not respond to anything. When I run the script from a console, 
the system responds to "console switch" function keys. Typed 
characters are echoed on the screen, though no higher functioning 
(switching to the Gnome window leads to a black, unresponsive screen).

Machine details: 2.6 GHz P-4, 1 Gb RAM, 500 Mb swap.

My script follows. I coded a loop to emulate the backup-to-CD utility 
that uncovered the bug. The system always hangs during the first copy. 
I use large file sizes because that's what originally triggered the 
hang. Smaller files (not sure how much smaller) successfully copied to 
the loop device.

----------
#!/bin/bash -x
# Demonstrates a loop device kernel hanging bug.
# Requirements:
#   2 Gb free space in current directory.
#   Loop device 0 is /dev/loop0.
#   Run script as root.
 
echo "Initialize virtual partition ..."
rm -rf vpartvmnt data
dd if=/dev/zero of=vpart bs=1M count=714
losetup /dev/loop0 vpart
mke2fs -q -m 0 -b 2048 /dev/loop0
mkdir vmnt
mount -o dev,suid /dev/loop0 vmnt
rm -rf vmnt/*
 
echo "Initialize test data ..."
dd if=/dev/urandom of=data bs=1M count=225
let I=1
while (true); do
    echo "Copying data.$I ..."
    cp data vmnt/data.$I
    if [ $? != 0 ]; then
        echo "Overflow. Removing data.$I ..."
        rm -f vmnt/data.$I
        exit
    fi
    let ++I
done
----------

Comment 3 Bugzilla owner 2004-09-30 15:39:45 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/