Messages in this thread |  | | | Date | Wed, 10 Mar 1999 11:27:07 +0200 (EET) | | From | Serguei Koubouchine <> | | Subject | Re: Fujitsu MO 640 doesn't work with 2.2.2? |
| |
On Tue, 9 Mar 1999, Alan Cox wrote:
> 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/
|  |