Adding second HD under ISC 2.0.2

[Thomas Hoberg]

I really didn't want to post this one, 'cause it's sooo long, but all my mail
to Mike McBain bounced....

-- 
In article <1991Feb12.065726.5497 at foster.avid.oz.au> you write:
|> I am having considerable difficulty adding a second hard disk to my
|> ISC 2.0.2 installation. I hope someone has some experience which can
|> help me.
|> 
|> Setup:
|> 
|> Micronics 486-25, 4MB memory.
|> Hard disk:  Primary WD APXXXX (209MB), IDE controller
|>             Secondary: Maxtor XT4380S, Future Domain TMC8XX controller
|> Tseng Labs VGA+ card and Nec 4D Multisync.
|> 
|> The kernel has been modified using kconfig so that it knows there
|> is a SCSI controller in the system. The system boots normally off
|> the IDE drive. 
This sounds like the IDE drive is considered the first physical drive (as I would
expect).
|> I have once or twice seen a message which says 
|>    tmc_init: no drives online
|> 
|> The Maxtor has been formatted under DOS. If the machine
|> is booted with DOS from the floppy drive, the Maxtor is accessible as drive C,
|> which tells me that it's electrically (and logically?) correctly installed.
What this tells me, is that the two controllers can't agree on who should be first. Drive C is usally used for the first physical drive, which should be the
IDE. I don't know what happens, if there is no DOS partition on the first drive.
If there is a DOS partition on the IDE drive, this means that the Future Domain
and the IDE don't get along.
|> 
|> However, when I try to add the Maxtor on its controller using the addharddisk
|> option under sysadm, I notice a few things:
|> 
|> 1. I select the format disk option having indicated the drive is drive
|>    0 on controller 1. It returns very quickly, and does not format
|>    the disk.
You might have formatted the IDE drive instead--be glad!
|> 2. My reading of the config files indicates that the minor number for
|>    the drive under these conditions should be 64. This seems sometimes
|>    to be OK, in that the /dev/dsk/c1d0s0 numbers have at times been  0, 64. 
|>    I could do a mknod by hand, of course. However, should the second controller
|>    have a major number of 0?
YES
|>    At the moment I'm letting addharddisk do all
|>    the work. Manual mknod with 0, 64-70 as the major and minor numbers
|>    for the c1d0s0-6 devices and 0, 192-6 for the c1d0p0-4 devices didn't get me
|>    anywhere.
c1d0s0 will point nowwhere, if the VTOC isn't initialized correctly, see below.
|> 3. Since it doesn't format the drive at all, it doesn't have a lot of success
|>    with mkfs and fdisk either.
|> 
|> I haven't put an entry into BIOS about this controller, since it's a SCSI one.
|> What else should I have tried? I have an Adaptec 1542B available to try if
|> that is likely to be better, but why doesn't it work as things are now? Anyone
|> seen this problem and solved it?
I think the Adaptec 1542B is a better choice anyway, and why not use it when you
have it? I have tried MFM/RLL/ESDI drives as primaries and Adaptec SCSI as secondary controllers without any problems. Since SCSI drives tend to be faster
than MFM/RLL/ESDI (though not necessarily IDE and perhaps not 20Mbit ESDI) it
would really be interesting to have the SCSI as primary drives. It should be 
possible to jumper the non-SCSI controller to the secondary address (0x17f and
IRQ 15) and hand patch it into the kernel (kconfig doesn't support that combination directly). The non-SCSI drives would be lost for DOS, though.

Doing mknod is only doing half the job. I don't trust 'addharddisk' all that much
and I don't like having to format the second hard disk (especially when it's a 
SCSI disk, that doesn't like to be formatted). I have had my first disk wiped out
several times and doing a re-install for the first hard disk is bad enough. But
addharddisk want's to destroy the second disk, when there is no need for doing
that. For Unix to be able to access the second disk's partitions it needs a
correct VTOC (volume table of contents) on the *second* disk which also describes
the physical characteristics of the device. There are some *really* messy IOCTL's
to do that, but there is also the rather cryptic program 'mkpart'. The VTOC and
the 'partition stanzas' are usually put on the disks via 'mkpart' during
formatting. They can also be put there by hand using 'mkpart -b'. 
'/etc/partitions' has to be edited to include the pysical characteristics of the
second drive. On one of my machines this currently looks like this:
(ESDI primary, RLL secondary)

disk0:     
	heads = 8, cyls = 966, sectors = 34, bpsec = 512,    
	physheads = 8, physcyls = 969, physsectors = 35, physbpsec = 512,    
	vtocsec = 29, altsec = 30, boot = "/etc/boot",     
	device = "/dev/rdsk/0p0"

root:
	partition = 1, start = 172720, size = 89760, 	
	tag = ROOT, perm = REMAP, perm = VALID 
  
swap0:
	partition = 2, start = 152864, size = 19856,	
	tag = SWAP, perm = NOMOUNT, perm = REMAP, perm = VALID
 
reserved0:
	partition = 8, start = 152320, size = 34, 	
	tag = BOOT, perm = NOMOUNT, perm = VALID 

alts0:
	partition = 9, start = 152592, size = 272, 	
	tag = ALTSCTR, perm = NOMOUNT, perm = VALID 


disk10:
    heads = 9, cyls = 925, sectors = 26, bpsec = 512,
    physheads = 9, physcyls = 925, physsectors = 35, physbpsec = 512,
    vtocsec = 29, altsec = 30, boot = "/etc/boot", device = "/dev/rdsk/c1d0p0",
    badsec = ( 11376,
               72473,
               78901,
               97592,
               114017,
               119107,
               137021,
               140121,
               140791,
               156145,
               170162,
               190651,
               190803,
               195297,
               203714,
               206391,
               209220,
               211209)

local10:
	partition = 2, start = 468, size = 215748,
	tag = USR, perm = REMAP, perm = VALID

rsrvd10:
	partition = 8, start = 234, size = 34,
	tag = BOOT, perm = NOMOUNT, perm = VALID

alts10:
	partition = 9, start = 286, size = 182,
	tag = ALTS, perm = NOMOUNT, perm = VALID


|> 
|> Mike McBain
|> -- 
|> Mike McBain             | DOMAIN: mjm at foster.avid.oz.au
|> Avid Systems Pty Ltd    | UUCP: {pyramid,uunet}!munnari!foster.avid.oz.au!mjm  
|> St Kilda, Australia 3182| Tel: +61 3 534 2293
|>           ---- Is it possible to knit during a space walk? ----

Hope this helps somewhere...
:-> tom
----
Thomas M. Hoberg   | UUCP: tmh at bigfoot.first.gmd.de  or  tmh%gmdtub at tub.UUCP
c/o GMD Berlin     |       ...!unido!tub!gmdtub!tmh (Europe) or
D-1000 Berlin 12   |       ...!unido!tub!tmh
Hardenbergplatz 2  |       ...!pyramid!tub!tmh (World)
Germany            | BITNET: tmh%DB0TUI6.BITNET at DB0TUI11 or
+49-30-254 99 160  |         tmh at tub.BITNET