Bug 77222 - Badblocks and fs corruption on Intel 845PE system and 2.4.18-17 RH rpm
Summary: Badblocks and fs corruption on Intel 845PE system and 2.4.18-17 RH rpm
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-03 16:24 UTC by Matt Dorsch
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-11-03 16:24:34 UTC


Attachments (Terms of Use)

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.)


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