Path: utzoo!attcan!uunet!van-bc!mdivax1!wilson Newsgroups: comp.os.minix Subject: 1.5 hard disks and shoelace Message-ID: <1990Oct1.161742.6509@mdivax1.uucp> Date: 1 Oct 90 16:17:42 GMT Reply-To: mdivax1!wilson (Paul Wilson) Organization: Mobile Data International, Richmond, B.C., Canada Lines: 41 Return-Path: Apparently-To: van-bc!rnews I have been busy trying to get the hard disk drivers and shoelace up and running on Minix 1.5.10 and have a few observations to share and one problem to solve. Firstly, I was not initially able to get shoelace to boot a Minix image containing the bios_wini.c hard disk driver. Everything went fine until time for the driver process to perform its initialization. At this point the light came on on the hard disk drive and everything froze. My first thought was that shoelace had managed to clobber the hard disk IRQ vector for the hard disk bios. Some diagnostic printf statements in the driver soon revealed that this was not the case. In the end I was able to fix the problem by invoking a bios reset of the controller. I did this by sending an "alternate reset" call to the bios before the parameter table is read. This required a call to bios13 with AH set to "0D" and DL set to the drive number. If you are using two drives, it should be done for each drive in turn. Now, on to my remaining problem; I cannot get the xt_wini.c driver to work correctly with my hardware. It is very close but I still have one remaining problem. The hardware is an Adaptec 8 bit RLL controller board and the disk is a Mitsubishi MR535. Unfortunately, I do not remember the mdel number of the controller and I do not have that information available to me at the office. The problem is that I can read the first 38 Meg or so of the disk but, if I try to read anything higher than that, I get an unrecoverable disk error. Specifically, the disk makes noises like it might be tryining to seek to a non-existant cylinder and then the driver gives up. I did find that the driver was confused over maximum head number (4) versus number of heads (5) causing it to calculate the cylinder number incorrectly. When I fixed this, the block number at which the problem occurred changed (as expected) but the cylinder number at which the problem occurred also changed (not expected). The problem does not occur at a place that seems likely. Specifically, it occurs in the middle of a track, not at head 0 and, most significantly, not when the leftmost 1 in the cylinder number propagates to the left. Unfortunately, I do not have any documentation on the disk controller card so I am reduced to poking around based on what I know of the disk bios operation and what I can figure out from the xt_wini.c code. Anyone have any suggestions as to how to solve this problem ? Paul Wilson ( ...!uunet!van-bc!mdivax1!wilson)