> The old fdisk and kernel both had bugs interpreting partition tables. On
> 2K media the counts are scaled down by a factor of 4 (versus 512 byte media).
> The 2.9i fdisk gets this right with fdisk -b 2048 as does th ekernel. This
> also means we can interwork now with M/O disks from other vendors
May be. But I can force kernel to panic when writing to the Fujitsu M2513EL
640 Mbyte MO. It's 100% repeatable. And yes, I do use the latest util-linux
and the rest of staff.
I have three SCSI controllers in the system - GDT6117RP with the only IBM
DGHS (18 Gbyte), NCR53C810A with a CD-recorder and aha152x with M2513EL and
Pioneer DR-U16S CD-ROM.
All this zoo did work with 2.2.0-pre6-ac2 rather fine. It did become
unreliable since 2.2.0 and still can be reliably crashed when writing to the
MO drive as of 2.2.2-ac7.
I'd rather blame gdth driver (both original included into the kernel and
the 1.18 version which has been sent to me by ICP vortex). It does have some
very subtle bugs (dunno whether it's a driver or controllers' (we have
several different kinds here) firmware to blame). The most prominent bug
shows itself as data corruption when reading data from a CD-ROM hooked to
the same GDTxxxx controller which the HDD is hooked to. You mount the CD and
have some files on it corrupted... No errors, all files are readable, only
some of them have content slightly different from that written onto the
CD... This very behaviour did force me to plug the aha152x into the
machine...
The machine can be reliably crashed by writing to (or even reading lotta
files from) the MO drive no matter whether it's plugged to the CDTxxxx or to
a separate controller. No crashes when reading files from MO one-by-one with
several seconds pause between reads. No crashes had been encountered on
2.2.0-pre6-ac2. Data corruption had been there since 2.1.129...
I do not encounter such problems on my home machine which is almost the same
except of BusLogic BT-958 instead of GDTxxxx. When writing onto the MO drive
machine stops periodically ( _VERY_ unresponsive when stopped) but after
about 30 seconds of heavy SCSI activity (nothing else is done during this
time, even compiler stops) it does resume. It's not right too, but it's
bearable....
I did send bug reports to ICP vortex and get a rather fast responce about
the misfeature of the gdth driver mapping HDDs after all other devices. They
did send me the new v1.18 driver which solves this problem but unfortunately
kernel crashes and data corruption are still there :-((
I have not got any responce from them for my letters sent after February
25...
===========================================================================
Serguei Koubouchine aka the Tamer < > The impossible we do immediately.
e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
===========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/