[lkml]   [2002]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject2.4.20-pre4-ac1 trashed my system


I've been a Linux user since 1994. I have always built my own
kernels. I have never trashed a system, until 2 nights ago, when I
ran 2.4.20-pre4-ac1...

Unfortunately what I have is very short on detail, because most of the
"evidence burned in the fire" when the disk's file systems were
destroyed. I do have .deb's of the suspect kernel (I'm a Debian user)
and I think I can recover the kernel .config file from that. Here's
what else I can supply:

o System: Athlon XP 1700+ CPU, built on an Asus A7V266-E mainboard.

o Ram: 512MB

o Disk: 160GB Maxtor IDE (note: >137GB)

o Controller: Promise 20265 rev 02 (as reported by lspci)

o Note: The Promise controller is not the primary controller on the
board. This is a second controller equipped on the board. I
point this out because the 160GB disk was connected to this
Promise controller, not the motherboard's default controller.

o I was using ext3 everywhere at the time things exploded.

o The previous kernel before 2.4.20-pre4-ac1 that I ran was
2.4.19-ac4, which ran OK on this hardware combination.

The first symptom I observed was a directory that listed incorrectly
as a file. It wasn't on my root file system so I unmounted it and
attempted an fsck. At this point I wasn't suspecting the new kernel
(I should have), otherwise I should have backed off to 2.4.19-ac4
first. But I didn't. This file system was about 120GB, most of the
disk; I hadn't noticed any trouble with other file systems yet.

The fsck went through about 60% of the file system cleanly and then
just went nuts reporting / fixing errors. Then fsck gave up,
complaining about something wrong with the journal file. I
reattempted it (second mistake); this time it died right away with the
same error. Then I noticed other processes hanging on the system. I
was unable to shut down so I power-cycled. The reboot paniced after
failing to find the init executable (though it did manage to mount

Going further down this trail of damage, I then tried to boot a rescue
partition (about 200MB) previously set up on the same disk. This was
a partition that was _not_ _mounted_ when 2.4.20-pre4-ac1 was running.
This boot attempt got as far as trying to start things in /etc/init.d
before croaking with a pile of SEGVs. I managed to fsck the rescue
partition but the damage had been done and that partition never worked
right again (i.e. corrupted files).

As far as I can tell now, the entire disk has been scrambled (except
for the partition table, which seems to have survived unscathed).

Also FWIW I did check kernel log message output during this melee and
saw nothing unusual, specifically no errors from the IDE subsystem.

The only things I see about this that might be noteworthy is:

1. I was using the Promise controller for my system disk, not the
board's primary controller.

2. I was using a 160GB drive, which exceeds the 137GB limit of ATA-5
(?). Notably, the initial fsck got ugly about 60% the way
through, which I _think_ would have put that right near the 137GB
boundary of the disk, given where that particular partition was
set up.

Is there a possible problem here with huge disk support using the
Promise 20265 controller in 2.4.20-pre4-ac1?

Unfortunately I need that system back so I'm rebuilding it now (and
moving the disk off of the Promise controller out of paranoia).

Is this a known problem with 2.4.20-pre4-ac1? I did note Alan's
statement about using the -ac series for further IDE development and
wonder if perhaps I got caught in the crosshairs.


| Mike Isely | PGP fingerprint
POSITIVELY NO | | 03 54 43 4D 75 E5 CC 92
UNSOLICITED JUNK MAIL! | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| (spam-foiling address) |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.128 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site