home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / sysv386 / 12211 < prev    next >
Encoding:
Text File  |  1992-07-21  |  3.6 KB  |  78 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!mcrware!mcrware!adam
  3. From: adam@microware.com (Adam Goldberg)
  4. Subject: Re: sector remapping woes with 1542A/SCO Unix
  5. Message-ID: <adam.711726087@mcrware>
  6. Organization: Microware Systems Corp., Des Moines, Iowa
  7. References: <467@wurtel.hobby.nl>
  8. Date: Tue, 21 Jul 1992 13:41:27 GMT
  9. Lines: 67
  10.  
  11. paul@wurtel.hobby.nl (Paul Slootman) writes:
  12.  
  13. >I have a strange problem. I recently added a SCSI controller and
  14. >disk to my 386 system (Adaptec 1540A and Fujitsu M2249SA (I think)).
  15. >I already have an Adaptec RLL controller with two drives in my machine.
  16.  
  17. >The problem is this: if I disable the two "standard" disks in the CMOS
  18. >setup of the machine, the Adaptec SCSI controller properly sees the
  19. >SCSI disk and installs it as C:. If I put DOS on it, there's no problem,
  20. >I can boot from it, run apps, etc.: everything works ok. The SCSI BIOS
  21. >remaps the sectors to 318 cylinders of 64 heads, 32 sectors, giving me
  22. >318 MB, which is right.
  23.  
  24. >However, when I access it from UNIX by installing SCO Unix 3.2.2, SCO
  25. >tells me it's a disk with 1272 cylinders, 16 heads, 32 sectors, also
  26. >giving me 318MB. However, after installing everything, I can't boot from
  27. >it ("NO OS").
  28.  
  29. >Some exploratory work shows me that the PC BIOS wants to load the stuff
  30. >from the hard disk, but does this using the first translation (64 heads).
  31. >As the partition table is written while 16 heads are assumed, the stuff
  32. >can't be found, and the bootstrap fails.
  33.  
  34. Perhaps some background would be helpful:
  35.  
  36. Because DOS relies on head/cylinder/sector information in the partition
  37. table (and the BIOS relies on it to load the bootstrap(s)), and because
  38. SCSI disks don't exactly have heads/cylinders/sectors (they just have
  39. sectors/blocks numbered 0..n), the Adaptec *real mode ROM/firmware* 
  40. takes the blocks numbered 0..n, and (logically) chops it up into 64
  41. heads, 32 sectors and M cylinders (where M is the size of the drive,
  42. in Mb, rounded down).
  43.  
  44. This is good, IMHO, because it allows standard BIOS disk access to work
  45. with the SCSI drives, while allowing up to 1G drives (1024 cylinders) without
  46. special drivers.  However, since the Big Ugly Monster of DOS defined the
  47. partition table without SCSI-foresight, the partition table must be
  48. in terms of these logical 64 head/32 sector cylinders.  
  49.  
  50. But, this poses a (slight) problem to protected-mode OSs (ie, every real
  51. OS <plug>), because the *real mode ROM/firmware* cannot be used in 
  52. protected mode.  Moreover, even if you could use it, you wouldn't want 
  53. to--the firmware is inherently single-threaded and cannot do background
  54. transfers.  
  55.  
  56. So what you have is a disk partitioned in terms of 1Mb logical cylinders,
  57. but to a PM OS, all you have is a disk with N sectors.  The OS must
  58. realize that the partition table only 'sees' the logical cylinders and
  59. deal with the partition table in that manner.
  60.  
  61. For some reason, Paul's Unix doesn't seem to realize that.  There is
  62. no difference (from a software point of view) between the 154{0,2}{a,b},
  63. therefore SCO is doing something really screwy.
  64.  
  65. There must be an option to SCO to force it to look at the partition
  66. table as 64h/32s cylinders.  I can't imagine that you should even NEED
  67. to do that.
  68.  
  69. But nevertheless, the problem remains.  Perhaps Paul should try to use
  70. a sector editor (or something like Norton Utils DISKEDIT) to create
  71. the Unix partition manually, then NOT CHANGE IT AT ALL with the SCO
  72. partition-table editor.  Maybe that'd work.
  73. -- 
  74. Adam G.
  75. adamg@microware.com, or ...!uunet!mcrware!adamg
  76. The above is not to be construed in any way as the official or unofficial
  77. statements of Microware, or any of it's employees.
  78.