buck@siswat.UUCP (A. Lester Buck) (04/16/89)
I am getting some strange behavior from Microport System V/AT v2.4 reading
bad blocks and was wondering if anyone had had this problem before.
I have a second disk which has the first 32 MB devoted to DOS,
and the rest to Unix. After full setup and bad track scan,
Microport 2.4 (correctly) found the following bad tracks on the disk.
(output from "showbad 1" for a Mitsubishi 535 RLL, 977 cyls, 5 heads)
Bad Track Table - Unit 1
Bad Cylinder Bad Head Alt. Cylinder Alt. Head
546 1 953 0
634 3 953 1
806 3 953 2
965 3 953 3
But reading the entire raw disk gives the following errors:
HD Err on read on drv 1 cyl 546 head 1 sec 23, Bad block
and similarly for cylinder 634 and 806. (965 does not show up
because the bad track scan resized the partition to make 964
the last cylinder.)
Does anyone know why the Microport driver is ignoring the bad track
information? It correctly uses the bad track information for
disk 0, which is a Seagate 277R RLL disk. My disk controller is
an Adaptec 2372 RLL.
I did have problems getting this second disk added recently. After
several combinations that did not allow DOS and Unix to coexist
on the same second disk, I found that the following sequence worked:
1) low level RLL format with Adaptec BIOS format from DEBUG
2) DOS 3.3 FDISK, pick full sized partition (starts at cyl 0)
3) DOS FORMAT D: (first disk has small DOS partition at C:)
4) boot Unix from 2.4 boot floppy
5) fdisk - shows DOS FDISK picked partition 4 in Unix's numbering
6) fdisk - make partition 1, Unix active, scan for bad blocks
7) divvy 1, put everything in /usr
8) normal boot from hard disk to Unix and mount /dev/dsk/1s2
Everything works fine except these annoying bad block glitches.
Is there something wrong with the above sequence?
BTW, where does Microport keep the bad track information and
is the format documented anywhere? And why does the bad track
scan dump a good 10 cylinders of this disk as it "resizes".
The manual says something about preventing subtle problems
at a future time.
Thanks for any help!
--
A. Lester Buck ...!texbell!moray!siswat!buck