Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 68673

Summary:	Kernel hangs when using loopback device
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <itooon>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.3	CC:	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/