cmilono@netcom.COM (Carlo Milono) (05/11/91)
I have an acquaintance who is attempting to install SVR4 on a 386/33 clone which as a 600MB hard drive. He initially had trouble getting the beast to do a low-level format, but finally <read the manuals>. When he booted the first floppy, it went and did a surface analysis...and did a regular format...and it stopped at cylinder 1023, making a total of 1024 cyls. Is there a limit to the number of cylinders that SVR4 can handle...is it at this "nice round HEX number"? I was at a loss to explain this as I have formatted 1GB drives with SVR4 (but didn't know about how many cylinders they had..they were SCSI and his are ESDI). -- +--------------------------------------------------------------------------+ | Carlo Milono: cmilono@netcom.apple.com or apple!netcom!cmilono | |"When a true genius appears in the world, you may know him by this sign, | |that the dunces are all in confederacy against him." - Jonathan Swift | +--------------------------------------------------------------------------+
wtm@uhura.neoucom.EDU (Bill Mayhew) (05/13/91)
Without knowing the specific release of Sys V r4, I can't say for sure what limited the winchester drive to formatting to only 1024 cylinders. Most likely the driver is coded with the assumption that the hardware will have the usual IBM ISA bus limits. The original IBM AT disk controller was the WD 1001 which could handle only 1024 cylinders. The 1024 cylinder limit is still hard coded into msdos unless one uses a third party driver such as On Track's Disk Manager or a smart controller. There is also a hard limit of 16 heads. The easiest solution is to use a controller to remap the geometry of the disk drive to make the drive appear to the operating system to have a maximum of 1024 cylinders. I'm using a Priam 330 megabyte ESDI drive on my Sys V r3.2.1 system that has about 1200 physical cylinders. The controller I'm using is a WD 1007 that does sector translation. I've not had any problems at all with the arragnement. I believe that even with the WD 1007, you're going to be limited to about 504 megabytes of accessible space by the translation 63 sectors * 16 heads * 1024 cylinders * 512 bytes = 504 megabytes. There really isn't a good excuse that Sys 4 should not support large disks on the ISA bus; disks and controllers with huge geometries have been available for quite some time now. Bill -- Bill Mayhew NEOUCOM Computer Services Department Rootstown, OH 44272-9995 USA phone: 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm via internet: (140.220.001.001)
rwhite@jagat.uucp (Robert White) (05/13/91)
Re: Large hard drive problem an a 386... The problem you describe has nothing to do with SVR4 per-se, it is a holdover from the IBM brain damage used to set the standard for the partition table. If you look in a DOS technical refrence manual you will discover that the number of bits set asside in the partition table for cylinder count is only capible of keeping a number in the range of 0-1023. Bigger hard drives are not allowed in the schema... The magic: Many hard disk controllers (read all intended for use with really big hard disks) have an option ROM which is evaluated durring boot and logically spliced into the system ROM. The feature ROM will contain a methodology for "remaping the physical geometry of your hard disk" (or some similarly obscure phrase). The technique goes something like this... (Consult your controller manual for exact procedures. If your controler is not capible of this activity you will need to get a different/better controler...) Use your system setup facility to indicate that the drive is either drive type zero (no drive) of drive type 1 (simple 10 meg drive) depending on the instructions contained in the controler manual. Reboot the computer using MS-DOS, Use the hardware boot (reset or power switch) and look for a diagnostic message telling you that there is an option ROM, note the address(es) presented. If your boot ROM does not give this information you can scower the controler manual for it. 8-of-10 times it will be C800. Load debug and execute a g=xxxx:5 where xxxx is the address from above (normally C800). This is the controller configuration subsystem. Something like *every* controller with an option ROM will have an interactive tool to do low level things to the drive starting at this address. You should have a simple menu in front of you. You will be given a choice which reads something like: "low level format and remap drive parameters" or "set drive geometry" or something. Pick that one and follow the directions... you will eventually be given the option to remap the geometry, pick a selection where the entire drive has less than 1024 cyls. Load up the UNIX Software and you are off... What you are doing: There are "special reserved areas" in the boot block for the hard drive which are outside the parition table and are not supposed to be overwritten by the boot program for the hard disk. the controler will write a few flag bytes in this area, which allows the controler to remember that it is to spoof the drive geometry. Durring the option ROM phase the controler reads this first sector and determines that spoofing is in order. It basicly pretends that the drive has either more heads per cylinder or more sectors per track, or both. Logicly this is like taking the extra magnetic media outside the first 1024 and using it to make more platters, or stretching the hub out into a bigger circle so there is more data in each revolution of the drive. The serious down side is that the software actually thinks that the hard drive has the new number of heads, tracks, etc. When every two or three cylinders are logically one cylinder, your drive scheduler will think it is parked over one cylinder when it is actually bouncing back and forth between several. Fortunately they will be adjcent to each other and most schedulers will write out the tracks in order from highest to lowest or lowest to highest as a matter of internal convience so the performance hit is not too severe. As a Caveat: Doing the g=c800:5 does cause some controlers to completely trash the boot block for the drive(s) in the system when spoofing information is involved. Most controlers assume that the rest of the block does not yet contain valid data and do nothing to preserve it. Doing this on an already installed system can make it unbootable. I have had this problem on one of the servers at work. *ALWAYS* do a backup of a system before you do this kind of low level stuff. On the system where this problem was encountered (I was adding a second drive) I used the first install disk for UNIX and broke out of the install script with a <del> at the first prompt. Mounted the real(tm) root partition from the hard disk and used the rewrite-boot-files option of the partitioning commmand (the name of the command escapes me at the moment). It took me two hours to figure out this fix... The lesson: don't panic (if you have a backup how bad can it be? 8-). Thank you IBM. -- Robert C. White Jr. | I have moved my news reading activities rwhite@jagat <Home | not directly related to my job off of my rwhite@nusdecs <Work | employers machine. Please use "jagat" "Like most endevors, life is seriously over-advertised and under-funded"