Bug 68673 - Kernel hangs when using loopback device
Kernel hangs when using loopback device
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-12 09:26 EDT by Need Real Name
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-07-12 09:26:30 EDT
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 09:30:18 EDT
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 03:25:00 EST
(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 11:39:45 EDT
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/

Note You need to log in before you can comment on or make changes to this bug.