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
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/ |