Hide Forgot
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.
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)
(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 ----------
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/