Bug 77222

Summary:	Badblocks and fs corruption on Intel 845PE system and 2.4.18-17 RH rpm
Product:	[Retired] Red Hat Linux	Reporter:	Matt Dorsch <dorscm>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.3
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:	2002-11-03 16:24:34 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 Matt Dorsch 2002-11-03 16:24:28 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-3 i686)

Description of problem:
I am upgrading from a FIC SD11 mobo to an Asus P4PE mobo. The Asus uses the
Intel 845PE chipset. The linux install is 7.3. When I first performed the
upgrade, I did run into the Ultra DMA issues previously reported. I upgraded to
2.4.18-17, and UDMA started working. However, yesterday I found my root
partition (ext2) with filesystem corruption after a clean shutdown. I ran fsck.
It found a few dozen errors, including bad dtimes, and "compression bit is set
for file on uncompressed filesystem". I ran badblocks. It found block 530112 to
be bad. (The partition has blocks 0 through 530113.) I downloaded Seagate's
drive tools to check the new ST380021A drive I had upgraded to. It found the
drive to be in perfect condition. I tried badblocks using the rescue mode on the
7.3 install CD. It complained that block 530112 was bad. I removed the drive and
placed it in the old SD11 system. I booted with the 7.3 CD. Badblocks found the
partition to be in perfect condition. As for the filesystem corruption, i'm not
sure how to reproduce it. I just used the system as I normally would. I'm not
even sure it's part of the same problem, though I would think they would be
symptoms of the same defect. What should I do next? 

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


How reproducible:
Always

Steps to Reproduce:
1. Place drive in my 845PE system.
2. Boot with 7.3 CD rescue mode.
3. Run badblocks on /dev/hda5.
(I have no idea how well this will reproduce on other 845PE systems with other
drives tho...)
	

Actual Results:  badblocks indicates 530112 is bad.

Expected Results:  No bad blocks should be found.

Additional info:

(I'm setting the severity to high because of the filesystem corruption. If you
want to change that, feel free to.)

Comment 1 Matt Dorsch 2002-11-03 21:00:19 UTC

Ok, the kernel does not seem to be the issue for the bad block indication. When
I use the rescue mode, one is given three options for mounting the host
filesystems: Continue (?), Read Only, and Skip. When I choose Continue, the
rescue process mounts my partitions as found in /etc/fstab under /mnt/sysimage.
When I do this, badblocks reports the bad block. If I just choose skip and leave
it unmounted, badblocks says it's a clean partition. I think the issue is that I
have had the filesystem mounted on certain tests, and not on others. Remind me
to use e2fsck -c next time, eh? I think I'm going to mark this as not a bug. If
I happen to run into fs errors in the future, I'll post more info.
My apologies for the false alarm. (Note: it seems that even in read-only mode,
something seems to be locking something on the partition. I can't unmount this
partition if I have the wizard mount it.)