Hello!
OK, I'll just tell the story in the order it happened:
A. I'm using 2.4.19-rc1-ac2, UDMA(66) enabled on primary master
(Maxtor 6L060J3, 60G). Works flawlessly under normal workloads, stress
testing not done - no observed problems. IDE DMA does not work against
the PX-W1610 on the second channel of the PDC (IDE channel/writer
completely hang when I try to enable it), well, it sucks (12x upwards
burning is impossible without BurnProof - no problem under Winblows),
but I can live with that for a few kernel versions.
B. The 60G disk breaks (bad sectors), I get a Maxtor 4G120J6 (120G)
drive as a temporary replacement. The planned course of action was to
block-copy from the old to the new drive, see what is salvagaeable and
what has to be restored from tapes (not all file systems on the disk
in question are on backup, such as the "gaming os"). That way I can
block-copy back when the replacement 60G arrives. Fun: The kernel on
the RH 7.3 install cds does not like the 120G disk (hangs on ide drive
detection). OK, so I boot from the old drive, umount/remount -o ro,
and do the block copy (using dd_rescue; total of ~20 bad sectors).
C. Copy is done, boot from the new drive. The 2.4.19-rc1-ac2 works,
but will not get the filesystems consistently fixed - i.e. it shows
problems, I let it fix them, I run fsck again, it shows different
problems, and so on.
D. I think the fs is hosed, format it and restore from backup. Next
fsck shows it has errors. Correct them. Just to be on the safe side,
reboot and fsck again. Guess what. So it seems that in this
configuration an fsck under 2.4.19-rc1-ac2 would corrupt the fs it's
trying to fix.
E. OK, so I compile more current kernels. 2.4.19 (final),
2.4.19-ac4. They don't like the disk either, hang forever (> 10 mins)
at "checking partitions: hde:" (hde is the only hdd connected to the
PDC).
F. Try 2.4.20-pre4-ac2. Warns about UDMA66 only possible with a
80-conductor cable, and that it is downgrading to UDMA33. Huh? The
"game OSs" on the same box do use the disk in UDMA66 mode without
further hiccups. Still hangs at "checking partitions: hde:", but only
for about 30 seconds. Then it complains about "Timeout waiting for
DMA", "dma_timer_expiry: dma status == 0x21"; says it's resetting the
primary channel. After a few repetitions of this it continues booting
with DMA disabled. So far, the system is stable in that configuration;
but not much fun :-(
Other important machine data:
GigaByte GA-6BX7+ (Intel 440BX, OnBoard PDC 20262)
Intel Pentium III 800
Matrox G450 32MB
NetGear FA-311
Adaptec 2940 (legacy scanner, cdrom, dvd-rom)
Is there "land in sight" regarding the PDC20262 support? Digging
around on the mailing list etc. shows mostly things like "except in
the known bad configurations", "has been like <this> forever", etc. -
Is there someplace I can get concise information about the state of
IDE support in particular? A listing of all the "black magic" options
which is not a year or more out of date would be nice, too...
>From my other point of view, as a system builder/integrator: Which
("cost-effective") IDE controllers or chipsets *do* work fast and
stable under Linux, and are supposed to stay that way a little while?
-- Warning -- rant ahead --
Are we going back to the times where you *require* SCSI to get decent
disk support in Unix? Except now it's not (purely) the hardware's
fault? Do not take this as an offence, please - just being frustrated
here. It's just that the main advantage of *ix over certain other OSs
- "no matter how hard I push it, it won't shred my data" - wich used
to hold true to Linux since at least 0.99.14 as well - seems to slowly
be going down the drain. Yes, I *could* run a kernel "old enough" to
be stable, but then I'd also like to take advantage of "average"
hardware and its new features. Not that the machine in question is
particularly 'cutting edge'. To make myself clear: Since I got that
machine a good 2 years ago I'm waiting for fast and stable IDE
support...
Sorry, that needed out... Anyway, keep up the great work!
So long,
Joe
--
"I use emacs, which might be thought of as a thermonuclear
word processor."
-- Neal Stephenson, "In the beginning... was the command line"
On Wednesday 28 August 2002 20.01, Joachim Breuer wrote:
> D. I think the fs is hosed, format it and restore from backup. Next
> fsck shows it has errors. Correct them. Just to be on the safe side,
> reboot and fsck again. Guess what. So it seems that in this
> configuration an fsck under 2.4.19-rc1-ac2 would corrupt the fs it's
> trying to fix.
>
After reading this I have to ask.
You are not trying to fsck a mounted partion are you?
/RogerL
--
Roger Larsson
Skellefte?
Sweden
Roger Larsson <[email protected]> writes:
> On Wednesday 28 August 2002 20.01, Joachim Breuer wrote:
>> D. I think the fs is hosed, format it and restore from backup. Next
>> fsck shows it has errors. Correct them. Just to be on the safe side,
>> reboot and fsck again. Guess what. So it seems that in this
>> configuration an fsck under 2.4.19-rc1-ac2 would corrupt the fs it's
>> trying to fix.
>
> After reading this I have to ask.
> You are not trying to fsck a mounted partion are you?
No sweat, I'm not. - BTW, anyone know since when it is again/when it
will be "safe" (as in not corrupting the fs) to use dump on a mounted
but idle fs? - I could use lvm snapshots as well, last I heard there
was some "bug" in the buffer cache corrupting data when dump was used
even on an ro, but mounted, fs.
So long,
Joe
--
"I use emacs, which might be thought of as a thermonuclear
word processor."
-- Neal Stephenson, "In the beginning... was the command line"